From wqeqweuqy at hotmail.com Sat Nov 1 03:15:21 2008 From: wqeqweuqy at hotmail.com (Neal Alexander) Date: Sat Nov 1 03:10:41 2008 Subject: [Haskell-cafe] Re: Memory efficiency questions for real-time graphics In-Reply-To: <9c72296b0810271903s31e9cf65y9818caf189ebd7ef@mail.gmail.com> References: <9c72296b0810271903s31e9cf65y9818caf189ebd7ef@mail.gmail.com> Message-ID: Even when generating one or more copies of "world" per frame the performance stays fine and allocations are minimal. From what ive seen, the OpenGL calls are whats going to bottle neck. loop (time, space) where loop = loop <=< runKleisli action where action = (ChronoSync.sync *** syncExternal channel) >>> Space.update >>> display >>> ChronoSync.yieldCPU From patperry at stanford.edu Sat Nov 1 05:02:18 2008 From: patperry at stanford.edu (Patrick Perry) Date: Sat Nov 1 04:57:24 2008 Subject: [Haskell-cafe] ANN: blas version 0.6 Message-ID: <83AA2ADD-CBD3-4C8B-B0FC-D00DDB63E1A2@stanford.edu> New version of BLAS bindings out. Now with support for the ST monad! This breaks backwards compatibility, unfortunately. More info (and some sample code) here: http://quantile95.com/2008/10/31/ann-blas-bindings-for-haskell-version-06/ Also, if you want to help, please let me know. There is plenty of work to do. Patrick From andrewcoppin at btinternet.com Sat Nov 1 08:53:14 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Nov 1 08:48:14 2008 Subject: [Haskell-cafe] Array bug? Message-ID: <490C513A.3030200@btinternet.com> Consider the following GHCi session: GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m Data.Array.IO Prelude Data.Array.IO> t <- newArray ((0,0),(5,4)) 0 :: IO (IOUArray (Int,Int) Int) Loading package array-0.1.0.0 ... linking ... done. Prelude Data.Array.IO> getBounds t ((0,0),(5,4)) Prelude Data.Array.IO> writeArray t (10,10) 5 *** Exception: Error in array index Prelude Data.Array.IO> writeArray t (7,3) 5 *** Exception: Error in array index Prelude Data.Array.IO> writeArray t (3,7) 5 Prelude Data.Array.IO> So the array has 0 <= x <= 5 and 0 <= y <= 4, and writing to (10,10) or (7,3) throws an exception. However, writing to (3,7) triggers no exception - despite being clearly out of range. Judging by the behaviour of the large, complex program I was debugging when I stumbled upon this, the coordinates "wrap round" to the next column. (!!) Obviously, writing to non-existent coordinates and not getting an exception is a Very Bad Thing. I was counting on writeArray (and readArray) to detect out-of-range coordinates so I could fix my code. But as you can see, it doesn't actually work as advertised. You have *no idea* how long I spent trying to track this bug down! >_< Is this a known bug? Is it likely to be fixed any time soon? (I'm guessing the bug is as simple is converting indicies to integers and then checking the integers are in-range, rather than the underlying index type.) From agocorona at gmail.com Sat Nov 1 09:15:54 2008 From: agocorona at gmail.com (Alberto G. Corona ) Date: Sat Nov 1 09:10:57 2008 Subject: [Haskell-cafe] number of references to a variable Message-ID: Is there a way to know the number of memory references for a variable?. The runtime must know it but i do not know if this available for the program trough any low level trick Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081101/4e6cffdb/attachment.htm From barsoap at web.de Sat Nov 1 09:33:15 2008 From: barsoap at web.de (Achim Schneider) Date: Sat Nov 1 09:28:29 2008 Subject: [Haskell-cafe] Re: number of references to a variable References: Message-ID: <20081101143315.39b4d730@solaris> "Alberto G. Corona " wrote: > Is there a way to know the number of memory references for a > variable?. The runtime must know it but i do not know if this > available for the program trough any low level trick > Flameproof vests, cheap and safe! Get yours now before it's too late! -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From andrewcoppin at btinternet.com Sat Nov 1 09:38:40 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Nov 1 09:33:40 2008 Subject: [Haskell-cafe] number of references to a variable In-Reply-To: References: Message-ID: <490C5BE0.1090300@btinternet.com> Alberto G. Corona wrote: > Is there a way to know the number of memory references for a variable?. > The runtime must know it but i do not know if this available for the > program trough any low level trick More precisely, the GC computes it each time it runs. (And only computes it precisely during a "major" pass, not the more frequent "minor" passes.) You can attach a finaliser to an object, and that'll allow you to know when the reference count reaches zero. But beyond that, I don't know. From bertram.felgenhauer at googlemail.com Sat Nov 1 10:14:30 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat Nov 1 10:09:41 2008 Subject: [Haskell-cafe] Array bug? In-Reply-To: <490C513A.3030200@btinternet.com> References: <490C513A.3030200@btinternet.com> Message-ID: <20081101141430.GA4203@zombie.inf.tu-dresden.de> Andrew Coppin wrote: > Consider the following GHCi session: > > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Prelude Data.Array.IO> t <- newArray ((0,0),(5,4)) 0 :: IO (IOUArray (Int,Int) Int) > Prelude Data.Array.IO> getBounds t > ((0,0),(5,4)) > Prelude Data.Array.IO> > > Is this a known bug? Is it likely to be fixed any time soon? (I'm guessing > the bug is as simple is converting indicies to integers and then checking > the integers are in-range, rather than the underlying index type.) Yes, it's a known bug - a conscious choice really. See http://hackage.haskell.org/trac/ghc/ticket/2120 It's somewhat ironic that this behaviour was introduced by a patch that made arrays safer to use in other respects. Bertram From andrewcoppin at btinternet.com Sat Nov 1 10:58:38 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Nov 1 10:53:37 2008 Subject: [Haskell-cafe] Array bug? In-Reply-To: <20081101141430.GA4203@zombie.inf.tu-dresden.de> References: <490C513A.3030200@btinternet.com> <20081101141430.GA4203@zombie.inf.tu-dresden.de> Message-ID: <490C6E9E.9060703@btinternet.com> Bertram Felgenhauer wrote: > Yes, it's a known bug - a conscious choice really. See > > http://hackage.haskell.org/trac/ghc/ticket/2120 > > It's somewhat ironic that this behaviour was introduced by a patch > that made arrays safer to use in other respects. > ...so it's *not* going to be fixed then? That's just fantastic. Nice to know that Haskell takes safety seriously... From miguelimo38 at yandex.ru Sat Nov 1 11:20:37 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Sat Nov 1 11:15:51 2008 Subject: [Haskell-cafe] Re: number of references to a variable In-Reply-To: <20081101143315.39b4d730@solaris> References: <20081101143315.39b4d730@solaris> Message-ID: <9B36FEBE-DC28-4695-8ACA-731DCDD63F32@yandex.ru> On 1 Nov 2008, at 16:33, Achim Schneider wrote: > "Alberto G. Corona " wrote: > >> Is there a way to know the number of memory references for a >> variable?. The runtime must know it but i do not know if this >> available for the program trough any low level trick >> > Flameproof vests, cheap and safe! Get yours now before it's too late! Save one for me, please! From bulat.ziganshin at gmail.com Sat Nov 1 11:20:51 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Nov 1 11:16:10 2008 Subject: [Haskell-cafe] Array bug? In-Reply-To: <20081101141430.GA4203@zombie.inf.tu-dresden.de> References: <490C513A.3030200@btinternet.com> <20081101141430.GA4203@zombie.inf.tu-dresden.de> Message-ID: <1304325383.20081101182051@gmail.com> Hello Bertram, Saturday, November 1, 2008, 5:14:30 PM, you wrote: > Yes, it's a known bug - a conscious choice really. See > http://hackage.haskell.org/trac/ghc/ticket/2120 does it possible to do both checks? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jmaessen at alum.mit.edu Sat Nov 1 13:51:21 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Sat Nov 1 13:46:26 2008 Subject: [Haskell-cafe] number of references to a variable In-Reply-To: <490C5BE0.1090300@btinternet.com> References: <490C5BE0.1090300@btinternet.com> Message-ID: <919CCB0A-D31C-4407-ACFB-67C8651931D3@alum.mit.edu> On Nov 1, 2008, at 9:38 AM, Andrew Coppin wrote: > Alberto G. Corona wrote: >> Is there a way to know the number of memory references for a >> variable?. The runtime must know it but i do not know if this >> available for the program trough any low level trick > > More precisely, the GC computes it each time it runs. (And only > computes it precisely during a "major" pass, not the more frequent > "minor" passes.) Even this isn't quite true for most GC algorithms. The GC only needs to compute whether there is 0 or >= 1 reference to a given location (with some special weasel words for stuff with finalizers defined). If you can see it, the answer is always >=1, so this information is much less useful than you might think! Usually the clever thing you want to know is "this is the sole reference to the pointed-to object". If that's what you're interested in, try looking up "one-bit reference counting", but note that like any accurate reference counting technique it's really inefficient in practice compared to GC. [There are efficient reference counting techniques, but they defer refcount updates in various subtle ways. Also, every ref count technique requires a cycle detector.] -Jan-Willem Maessen From andrewcoppin at btinternet.com Sat Nov 1 13:56:03 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Nov 1 13:51:00 2008 Subject: [Haskell-cafe] number of references to a variable In-Reply-To: <919CCB0A-D31C-4407-ACFB-67C8651931D3@alum.mit.edu> References: <490C5BE0.1090300@btinternet.com> <919CCB0A-D31C-4407-ACFB-67C8651931D3@alum.mit.edu> Message-ID: <490C9833.4000704@btinternet.com> Jan-Willem Maessen wrote: > > On Nov 1, 2008, at 9:38 AM, Andrew Coppin wrote: > >> Alberto G. Corona wrote: >>> Is there a way to know the number of memory references for a >>> variable?. The runtime must know it but i do not know if this >>> available for the program trough any low level trick >> >> More precisely, the GC computes it each time it runs. (And only >> computes it precisely during a "major" pass, not the more frequent >> "minor" passes.) > > Even this isn't quite true for most GC algorithms. The GC only needs > to compute whether there is 0 or >= 1 reference to a given location. > If you can see it, the answer is always >=1, so this information is > much less useful than you might think! Quite right. > Usually the clever thing you want to know is "this is the sole > reference to the pointed-to object". Does GHC have weak references? (I seem to recall it does...) From t.r.willingham at gmail.com Sat Nov 1 14:57:54 2008 From: t.r.willingham at gmail.com (T Willingham) Date: Sat Nov 1 14:52:56 2008 Subject: [Haskell-cafe] Memory efficiency questions for real-time graphics In-Reply-To: <3d96ac180810281224h69dc0fb7m2a84882bdecafa7c@mail.gmail.com> References: <9c72296b0810271903s31e9cf65y9818caf189ebd7ef@mail.gmail.com> <3d96ac180810281224h69dc0fb7m2a84882bdecafa7c@mail.gmail.com> Message-ID: <9c72296b0811011157ke3b6815o7a69653efd8cca92@mail.gmail.com> On Tue, Oct 28, 2008 at 3:24 PM, Sebastian Sylvan wrote: > 2008/10/28 T Willingham >> >> To give a context for all of this, I am applying a non-linear >> transformation to an object on every frame. (Note: non-linear, so a >> matrix transform will not suffice.) > > Any reason why you can not do this in the vertex shader? You really should > avoid trying to touch the vertices with the CPU if at all possible. The per-vertex computation is a quite complex time-dependent function applied to the given domain on each update. Yet even if it were simple, I would still first implement the formulas in Haskell and leave the optimization for later, if at all. The current C++ implementation which uses userland-memory vertex arrays already performs very well. On Sat, Nov 1, 2008 at 3:15 AM, Neal Alexander wrote: > Even when generating one or more copies of "world" per frame the performance > stays fine and allocations are minimal. Who says? That may be your particular experience from your particular tests. In my case, any copy of the "world" on each frame would have a catastrophic effect on the framerate, for any such definition of "world". > From what ive seen, the OpenGL calls are whats going to bottle neck. Yes, that may as well be a tautology. The problem is sporadic lag and jittering from occasional large allocations and/or garbage collection from frequent small allocations. It's a unique situation where even the best profiling cannot pinpoint what is blatantly obvious to the human eye. Though the profiler may register it as 0.01%, the actual effect is glitchy behavior which comes off as unprofessional. From dons at galois.com Sat Nov 1 15:39:26 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 1 15:34:11 2008 Subject: [Haskell-cafe] ANN: blas version 0.6 In-Reply-To: <83AA2ADD-CBD3-4C8B-B0FC-D00DDB63E1A2@stanford.edu> References: <83AA2ADD-CBD3-4C8B-B0FC-D00DDB63E1A2@stanford.edu> Message-ID: <20081101193926.GB12261@scytale.galois.com> patperry: > New version of BLAS bindings out. Now with support for the ST monad! > This breaks backwards compatibility, unfortunately. > > More info (and some sample code) here: > http://quantile95.com/2008/10/31/ann-blas-bindings-for-haskell-version-06/ > > Also, if you want to help, please let me know. There is plenty of > work to do. > Great work! This stuff was sorely needed, so I'm glad a champion has appeared to lead the work. -- Don From byorgey at seas.upenn.edu Sat Nov 1 16:42:05 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Nov 1 16:37:08 2008 Subject: [Haskell-cafe] Haskell Weekly News: Issue 91 - November 1, 2008 Message-ID: <20081101204205.GA5464@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20081101 Issue 91 - November 01, 2008 --------------------------------------------------------------------------- Welcome to issue 91 of HWN, a newsletter covering developments in the [1]Haskell community. Announcements blas version 0.6. Patrick Perry [2]announced a [3]new version of the Haskell BLAS bindings, now with support for the ST monad! darcs hacking sprint #1 (report). Eric Y. Kow [4]summarized the [5]progress made during the darcs hacking sprint last weekend. Looks like exciting stuff! Much more detail and links can be found in Eric's original email. LAST CALL: Haskell Communities and Activities Report. Janis Voigtlaender [6]is extending the submission deadline for the 15th edition of the Haskell Community and Activities Report by a few days. If you haven't already, please [7]write an entry for your new project or update your old entry. Data.TCache 0.5.1. Alberto G. Corona [8]announced the release of [9]Data.TCache, which implements a transactional cache with configurable persistence. It tries to simulate Hibernate for Java or Rails for Ruby; the main difference is that transactions are done in memory trough STM. multirec-0.1. Andres Loeh [10]announced the release of the [11]multirec package, which provides a mechanism to talk about fixed points of systems of datatypes that may be mutually recursive. On top of this representations, generic functions such as the fold or the Zipper can then be defined. Making 'Super Nario Bros.' in Haskell. Korcan Hussein [12]linked to a [13]super mario brothers clone which was [14]written in Haskell! Chart-0.9. Tim Docker [15]announced the 0.9 release of the [16]Chart library, a library for drawing 2D charts. Publication of InputYourData.com + Project Announcement. Enzo Haussecker [17]announced the publication of [18]InputYourData.com, an online tool, written in Haskell, for financial, mathematical and scientific calculations. Enzo also described an idea to create a similar website where web applications are created by the user. If you are intrigued by this project and have substantial experience in designing Haskell-based web applications, please send Enzo your resume and a brief summery of why you are interested. Blog noise [19]Haskell news from the [20]blogosphere. * Mark Jason Dominus: [21]Atypical Typing. Mark describes his OOPSLA talk about Haskell's type system. * Eric Kow (kowey): [22]official darcs blog!. * Ben Moseley: [23]2 Minute intro to Associated Types / Type Families. * Ivan Lazar Miljenovic: [24]Honours + LXDE. Ivan discusses the status of his Haskell-oriented Mathematics Honours thesis. * Jason Dagit: [25]Darcs Hacking Sprint - Summary from Portland Team. * Eric Kow (kowey): [26]darcs hacking sprint - Team Brighton Day 2. * Dan Piponi (sigfpe): [27]Operads and their Monads. Quotes of the Week * lispy: I just wanted to make sure that this was illegal first * quicksilver: it doesn't entirely help that SQL is a series of broken standards layered over very poor decisions by large corporations * Baughn: SingInTime> hello world SingInTime: Type mismatch: Expected type: IRC [a], inferred type: IO () About the Haskell Weekly News New editions are posted to [28]the Haskell mailing list as well as to [29]the Haskell Sequence and [30]Planet Haskell. [31]RSS is also available, and headlines appear on [32]haskell.org. To help create new editions of this newsletter, please see the information on [33]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [34]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://article.gmane.org/gmane.comp.lang.haskell.cafe/47117 3. http://quantile95.com/2008/10/31/ann-blas-bindings-for-haskell-version-06/ 4. http://article.gmane.org/gmane.comp.lang.haskell.cafe/47114 5. http://blog.darcs.net/2008/10/darcs-hacking-sprint-1-report.html 6. http://article.gmane.org/gmane.comp.lang.haskell.cafe/47078 7. http://www.haskell.org/pipermail/haskell/2008-October/020651.html 8. http://article.gmane.org/gmane.comp.lang.haskell.cafe/47016 9. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/TCache 10. http://article.gmane.org/gmane.comp.lang.haskell.general/16574 11. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/multirec 12. http://article.gmane.org/gmane.comp.lang.haskell.general/16572 13. http://uk.youtube.com/watch?v=gVLFGQGRsDw 14. http://svn.coderepos.org/share/lang/haskell/nario/ 15. http://article.gmane.org/gmane.comp.lang.haskell.general/16570 16. http://dockerz.net/software/chart.html 17. http://article.gmane.org/gmane.comp.lang.haskell.general/16550 18. http://inputyourdata.com/ 19. http://planet.haskell.org/ 20. http://haskell.org/haskellwiki/Blog_articles 21. http://blog.plover.com/talk/atypical-typing.html 22. http://koweycode.blogspot.com/2008/10/official-darcs-blog.html 23. http://nattermorphisms.blogspot.com/2008/10/2-minute-intro-to-associated-types-type.html 24. http://ivanmiljenovic.wordpress.com/2008/10/29/honours-lxde/ 25. http://blog.codersbase.com/2008/10/28/darcs-hacking-sprint-summary-from-portland-team/ 26. http://koweycode.blogspot.com/2008/10/darcs-hacking-sprint-team-brighton-day.html 27. http://sigfpe.blogspot.com/2008/10/operads-and-their-monads.html 28. http://www.haskell.org/mailman/listinfo/haskell 29. http://sequence.complete.org/ 30. http://planet.haskell.org/ 31. http://sequence.complete.org/node/feed 32. http://haskell.org/ 33. http://haskell.org/haskellwiki/HWN 34. http://code.haskell.org/~byorgey/code/hwn/ From wqeqweuqy at hotmail.com Sat Nov 1 17:20:38 2008 From: wqeqweuqy at hotmail.com (Neal Alexander) Date: Sat Nov 1 17:15:59 2008 Subject: [Haskell-cafe] Re: Memory efficiency questions for real-time graphics In-Reply-To: <9c72296b0811011157ke3b6815o7a69653efd8cca92@mail.gmail.com> References: <9c72296b0810271903s31e9cf65y9818caf189ebd7ef@mail.gmail.com> <3d96ac180810281224h69dc0fb7m2a84882bdecafa7c@mail.gmail.com> <9c72296b0811011157ke3b6815o7a69653efd8cca92@mail.gmail.com> Message-ID: T Willingham wrote: > On Sat, Nov 1, 2008 at 3:15 AM, Neal Alexander wrote: >> Even when generating one or more copies of "world" per frame the performance >> stays fine and allocations are minimal. > > Who says? That may be your particular experience from your particular > tests. In my case, any copy of the "world" on each frame would have a > catastrophic effect on the framerate, for any such definition of > "world". > Yea, this is just from my recent experience messing with a game engine in Haskell - I'm only a few months into it though. So far, the GC hasn't been anywhere close to having a problem keeping up with the monitors refresh rate. Even with several world states being folded into a frame. The memory usage is pretty flat too, at least with GLFW (the GLUT bindings had some issues there iirc). The test is pulling a pretty constant 1500 fps on this machine with the background + 1 character running around and resources being streamed in lazily. Not that that means much, but at the very least a GC run isn't noticeable on the current data set. Initially i expected this setup to perform badly, but i tried it anyway out of curiosity. We'll see how it goes with full sets of data later i guess heh. From dons at galois.com Sat Nov 1 17:34:58 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 1 17:29:42 2008 Subject: [Haskell-cafe] Re: Memory efficiency questions for real-time graphics In-Reply-To: References: <9c72296b0810271903s31e9cf65y9818caf189ebd7ef@mail.gmail.com> <3d96ac180810281224h69dc0fb7m2a84882bdecafa7c@mail.gmail.com> <9c72296b0811011157ke3b6815o7a69653efd8cca92@mail.gmail.com> Message-ID: <20081101213458.GC12261@scytale.galois.com> wqeqweuqy: > T Willingham wrote: > > >On Sat, Nov 1, 2008 at 3:15 AM, Neal Alexander > >wrote: > >>Even when generating one or more copies of "world" per frame the > >>performance > >>stays fine and allocations are minimal. > > > >Who says? That may be your particular experience from your particular > >tests. In my case, any copy of the "world" on each frame would have a > >catastrophic effect on the framerate, for any such definition of > >"world". > > > > Yea, this is just from my recent experience messing with a game engine > in Haskell - I'm only a few months into it though. > > So far, the GC hasn't been anywhere close to having a problem keeping up > with the monitors refresh rate. Even with several world states being > folded into a frame. > > The memory usage is pretty flat too, at least with GLFW (the GLUT > bindings had some issues there iirc). > > The test is pulling a pretty constant 1500 fps on this machine with the > background + 1 character running around and resources being streamed in > lazily. Not that that means much, but at the very least a GC run isn't > noticeable on the current data set. > > > Initially i expected this setup to perform badly, but i tried it anyway > out of curiosity. We'll see how it goes with full sets of data later i > guess heh. > And, just to double check, you're compiling with a modern GHC, using say, -O2 -fvia-C -optc-O2 -funbox-strict-fields ? -- Don From bos at serpentine.com Sat Nov 1 17:35:59 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sat Nov 1 17:31:01 2008 Subject: [Haskell-cafe] An irritating Parsec problem In-Reply-To: <1224098439.19010.25.camel@jcchost> References: <48F6430B.7010104@btinternet.com> <1224098439.19010.25.camel@jcchost> Message-ID: On Wed, Oct 15, 2008 at 12:20 PM, Jonathan Cast wrote: > This is a bit > easier if you supply the missing Applicative instance: > > const <$> parser <*> eof > > Too verbose. parser <* eof -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081101/b63e590c/attachment.htm From wqeqweuqy at hotmail.com Sat Nov 1 17:57:29 2008 From: wqeqweuqy at hotmail.com (Neal Alexander) Date: Sat Nov 1 17:52:45 2008 Subject: [Haskell-cafe] Re: Memory efficiency questions for real-time graphics In-Reply-To: <20081101213458.GC12261@scytale.galois.com> References: <9c72296b0810271903s31e9cf65y9818caf189ebd7ef@mail.gmail.com> <3d96ac180810281224h69dc0fb7m2a84882bdecafa7c@mail.gmail.com> <9c72296b0811011157ke3b6815o7a69653efd8cca92@mail.gmail.com> <20081101213458.GC12261@scytale.galois.com> Message-ID: Don Stewart wrote: > wqeqweuqy: >> T Willingham wrote: >> >>> On Sat, Nov 1, 2008 at 3:15 AM, Neal Alexander >>> wrote: >>>> Even when generating one or more copies of "world" per frame the >>>> performance >>>> stays fine and allocations are minimal. >>> Who says? That may be your particular experience from your particular >>> tests. In my case, any copy of the "world" on each frame would have a >>> catastrophic effect on the framerate, for any such definition of >>> "world". >>> >> Yea, this is just from my recent experience messing with a game engine >> in Haskell - I'm only a few months into it though. >> >> So far, the GC hasn't been anywhere close to having a problem keeping up >> with the monitors refresh rate. Even with several world states being >> folded into a frame. >> >> The memory usage is pretty flat too, at least with GLFW (the GLUT >> bindings had some issues there iirc). >> >> The test is pulling a pretty constant 1500 fps on this machine with the >> background + 1 character running around and resources being streamed in >> lazily. Not that that means much, but at the very least a GC run isn't >> noticeable on the current data set. >> >> >> Initially i expected this setup to perform badly, but i tried it anyway >> out of curiosity. We'll see how it goes with full sets of data later i >> guess heh. >> > > And, just to double check, you're compiling with a modern GHC, using > say, -O2 -fvia-C -optc-O2 -funbox-strict-fields ? > > -- Don Yea the optimization flags don't have any real effect on the FPS atm. The engine is bottlenecked by the OGL specific stuff. The way it looks now i don't think theres going to be any performance problems - not that this is trying to be a bleeding edge 3d engine, but whatever. Tree data structures seem to adapt pretty well to being recreated each frame. I'm not sure how smart the GC is in regards to that though. Using matrices the same way performed really poorly. Replacing the matrix with a Region-QuadTrie caused a huge performance boost. IIRC the matrix stuff was using like 30% cpu according to the profile data and the Tree based approach used basicly 0% heh. From briqueabraque at yahoo.com Sun Nov 2 08:31:34 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Sun Nov 2 08:26:42 2008 Subject: [Haskell-cafe] Re: Newbie on instance of Monad In-Reply-To: References: Message-ID: >> Hi, >> >> After a lot of thinking, I can't get what I >> am doing wrong in this code: >> (...) >> data ( RandomGen g ) => RandomMonad g a = RandomMonad (g -> a) > > RandomGen g is considered the constraint for the application of > RandomMonad constructor, but GHC does not conclude that every value of > (RandomMonad g a) fulfills this constraint. Actually, 'undefined' is > available for any 'g'. > > you need to make (RandomGen g) a constraint of the instance: > > instance RandomGen g => Monad (RandomMonad g) where Nice. I wasn't so wrong as I though :) I didn't understand why can't the compiler deduce that g is always going to be of type RandomGen. Even if I use 'undefined', it has to be a RandomGen undefined. > Btw. RandomMonad looks like Control.Monad.Reader. You are right, I'll try that instead so I learn a little bit more. But I can't understand this syntax: class (Monad m) => MonadReader r m | m -> r where What is the '|' doing there? I'll post that in a new thread since it's a different question. Thanks, Maur?cio From briqueabraque at yahoo.com Sun Nov 2 08:41:10 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Sun Nov 2 08:36:19 2008 Subject: [Haskell-cafe] Syntax question: class (Monad m) => MonadReader r m | m -> r where Message-ID: Hi, I've reading Control.Monad.Reader source code and arrived here: class (Monad m) => MonadReader r m | m -> r where I can't understand that syntax. Since this is not a 'data' line, what is the '|' supposed mean? Thanks, Maur?cio From andrewcoppin at btinternet.com Sun Nov 2 08:46:43 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun Nov 2 08:41:38 2008 Subject: [Haskell-cafe] Syntax question: class (Monad m) => MonadReader r m | m -> r where In-Reply-To: References: Message-ID: <490DAF43.8080901@btinternet.com> Mauricio wrote: > Hi, > > I've reading Control.Monad.Reader source code and > arrived here: > > class (Monad m) => MonadReader r m | m -> r where > > I can't understand that syntax. Since this is not a > 'data' line, what is the '|' supposed mean? It's called a "functional dependency". This is not part of the Haskell-98 language standard; check the GHC manual. From marco-oweber at gmx.de Sun Nov 2 08:47:50 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Nov 2 08:42:52 2008 Subject: [Haskell-cafe] Need help with VXML again (fun deps and forall types) Message-ID: <20081102134750.GA19947@gmx.de> Some time I've announced that I'm working on VXML, a validating xml library. The use case which makes trouble is elem+ (one or more) This example is encoded in this way: root -> St 1 id :1 endable : True a -> St 1 b -> St 1 c -> St 12 id :11 endable : True (a|b|c) -> St 1 d -> St 11 id :12 endable : False d -> St 11 to be read as: When creating a new root element start with state 1, then expect one of a,b,c subelemnts. If subelement c is added continue with state 12. The element may not be finalized (endable false because a "d" is expected). Following that we end in a loop at state 11 which is endable when only adding more d subelemnts. in VXML it looks like this print $ fStr $ runRoot $ vdo -- forceElements c e d e -- first, result has state 12 A d e -- second, result has state 11 X d e -- thrd, result has state 11 d e -- fourth, result has state 11 Y -- ... Now I'd like to do something convinient such as foldr1 (>>) print $ [1..10] I've called the corresponding function in VXML vxmlgtgt because it can be used like a monad and even do notation is supported using the vdo cpp macro rebinding (>>), (>>=) and return. Obviously I can only use foldr from X up to Y because A has a different return type. If you download the latest version of the library (git clone git://mawercer.de/vxml; git checkout fc160ab # is master branch ) you see that it actually works quite fine -- helper function: vxmlSeqPlus_ (f,fl) = f `vxmlgtgt` (foldr1 vxmlgtgt fl) -- usage example from testSimple.hs, note that both (d e) have different types vxmlSeqPlus_ ((d e), replicate 9 (d e)) d is actually a function creating the d element requiring a function as first argument which adds attrubutes and subelemnts (e is a nop here) This all makes d having a type which looks rather complicated: el*: the result type (String only in the current implementation) data VXML st el_ st2 el2_ st3 el3_ a = VXML { runVVXML :: (PT st el_ -> PT st2 el2_) -- [1] -> (a, PT st el_ -> PT st3 el3_) -- [2] } [1] : st -> st2 : The function which is passed [2] : st -> st3 : The type of function which is returned taking a function modyfiying the parent and adding "d" resulting in st3 (st3 is either State12 in A, or State11 in Y talking about the example given above) Its even getting more interesting now: Because I'd like to use different result types (String, ByteString, ...) I've used a type var to represent that type. I've called them el el2 el3 etc. When finally creating the document by using runRoot the result types propagates through the xml tree by functional dependencies. An example is the AddElT class which actually does add a subelement: class AddElT est el_ estc elc_ est2 el2_ | est estc -> est2 -- result state is determined by parent and child element state , est est2 estc el2_ -> el_ -- the result type of child and parent privious sibling are determined by the el2_ return type and the element states , est est2 estc el2_ -> elc_ where addElT :: PT est el_ -> PT estc elc_ -> PT est2 el2_ The instance has constraints like this determining el_ elc_ and st2 instance ( , DetermineElAddEl (NYV (Element elType AttrsOk st hchs)) el2 cest2 elc2 (NYV (Element elType AttrsOk st2 HTrue)) el3 , Consume st (Elem celType) st2 [..] ) => AddElT [..] Determining states form leafs to the root then propagating String or ByteString result type form the root to the leaf depending on states works fine until I start trying to use shortcut for the foldr1 example above. Instead of vxmlSeqPlus_ ((d e), replicate 9 (d e)) I'd like to write this. Of course the lamba here is polymorphic because it must return State 12 the first time and State 11 in the following cases. vxmlMapSeqPlus_ (\_ -> d e) [1..10] -- Ex I It's implementation is straight forward: vxmlMapSeqPlus_ f (x:xs) = vxmlSeqPlus_ (f x, map f xs) vxmlMapSeqPlus_ _ [] = error "vxmlSeqPlus has been called with empty list" My attempt to assign a type looks like this: vxmlMapSeqPlus_ :: ( VXMLMonad m st el st2 el2 st3 el3 st3 el3 , VXMLMonad m st el st3 el3 st3 el3 st3 el3 ) => (forall st' elA st'' elB . t -> m st el st' elA st'' elB ()) -> [t] -> m st el st2 el2 st3 el3 () vxmlMapSeqPlus_ f (x:xs) = vxmlSeqPlus_ (f x , map f xs) vxmlMapSeqPlus_ _ [] = error "vxmlSeqPlus has been called with empty list" where class VXMLMonad m st el_ st2 el2_ st3 el3_ st4 el4_ where vxmlgtgt :: m st el_ st2 el2_ st3 el3_ a -> m st el_ st3 el3_ st4 el4_ b -> m st el_ st2 el2_ st4 el4_ b vxmlgtgt a b = vxmlbind a $ const b vxmlbind :: m st el_ st2 el2_ st3 el3_ a -> (a -> m st el_ st3 el3_ st4 el4_ b) -> m st el_ st2 el2_ st4 el4_ b However when compiling the example (Ex I) there are a bunch of errors telling me that ghc can't find the matching instances caused by missing specialization of st.. That is ghc does no longer determine the resulting state based on parent and previous childs. Without state it can't propagate the el type ... You can see both examples in testSimple.hs vxmlSeqPlus_ ((d e), replicate 9 (d e)) vxmlMapSeqPlus_ (\n -> d e ) [1..10] So my question is: The second line does work fine, the first one dosen't. How to write vxmlMapSeqPlus_ so that I can compile the example? vxmlMapSeqPlus_ (\n -> d e ) [1..10] (d e) `vxmlgtgt` (foldr1 vxmlgtgt $ map (const $ d e) [2..10]) If you want to try this with ghc older than 6.10 you'll have to rewrite the vdo notation using vxmlbind and vxmlgtgt.. Do you have any idea how to make this work as expected? That's the last issue preventing me from trying to use it in real life projects. Sincerly Marc Weber From agocorona at gmail.com Sun Nov 2 09:02:10 2008 From: agocorona at gmail.com (Alberto G. Corona ) Date: Sun Nov 2 08:57:10 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: RefSerialize-0.2.1 Message-ID: I uploadad RefSerialize to Hackage . Read, Show and Data.Binary do not check for repeated references to the same data address. As a result, the data is serialized multiple times when serialized. This is a waste of space in the filesystem and also a waste of serialization time. but the worst consequence is that, when the serialized data is read, it allocates multiple copies in memory for the same object referenced multiple times. Because multiple referenced data is very typical in a pure language such is Haskell, this means that the resulting data loose the beatiful economy of space and processing time that referential transparency permits. This package allows the serialization and deserialization of large data structures without duplication of data, with the result of optimized performance and memory usage. It is also useful for debugging purposes. There are automatic derived instances for instances of Read/Show, lists and strings. the deserializer contains a almos complete set of Parsec.Token parsers for deserialization. Every instance of Show/Read is also a instance of Data.RefSerialize The serialized string has the form "expr( var1, ...varn) where var1=value1,..valn=valueN " so that the string can ve EVALuated. See demo.hs and tutorial. I presumably will add a entry in haskell-web.blogspot.com To develop: -derived instances for Data.Binary -serialization to/from ByteStings I wrote this module because I needed to serialize lists of verisions of the same data with slight modifications between each version. This is a short tutorial (in tutorial.txt) runW applies showp, the serialization parser of the instance Int for the RefSerialize class Data.RefSerialize>let x= 5 :: Int Data.RefSerialize>runW $ showp x "5" every instance of Read and Show is an instance of RefSerialize. rshowp is derived from showp, it labels the serialized data with a variable name Data.RefSerialize>runW $ rshowp x " v8 where {v8= 5; }" Data.RefSerialize>runW $ rshowp [2::Int,3::Int] " v6 where {v6= [ v9, v10]; v9= 2; v10= 3; }" while showp does a normal show serialization Data.RefSerialize>runW $ showp [x,x] "[5, 5]" rshowp variables are serialized memory references: no piece of data that point to the same addrees is serialized but one time Data.RefSerialize>runW $ rshowp [x,x] " v9 where {v6= 5; v9= [ v6, v6]; }" This happens recursively Data.RefSerialize>let xs= [x,x] in str = runW $ rshowp [xs,xs] Data.RefSerialize>str " v8 where {v8= [ v10, v10]; v9= 5; v10= [ v9, v9]; }" the rshowp serialized data is read with rreadp. The showp serialized data is read by readp Data.RefSerialize>let xss= runR rreadp str :: [[Int]] Data.RefSerialize>print xss [[5,5],[5,5]] this is the deserialized data the deserialized data keep the references!! pointers are restored! That is the whole point! Data.RefSerialize>varName xss !! 0 == varName xss !! 1 True rShow= runW rshowp rRead= runR rreadp Data.RefSerialize>rShow x " v11 where {v11= 5; }" In the definition of a referencing parser non referencing parsers can be used and viceversa. Use a referencing parser when the piece of data is being referenced many times inside the serialized data. by default the referencing parser is constructed by: rshowp= insertVar showp rreadp= readVar readp but this can be redefined. See for example the instance of [] in RefSerialize.hs This is an example of a showp parser for a simple data structure. data S= S Int Int deriving ( Show, Eq) instance Serialize S where showp (S x y)= do xs <- rshowp x -- rshowp parsers can be inside showp parser ys <- rshowp y return $ "S "++xs++" "++ys readp = do symbol "S" -- I included a (almost) complete Parsec for deserialization x <- rreadp y <- rreadp return $ S x y there is a mix between referencing and no referencing parser here: Data.RefSerialize>putStrLn $ runW $ showp $ S x x S v23 v23 where {v23= 5; } (I corrected some errors in this file here) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081102/cf532cf9/attachment.htm From xs at xaph.net Sun Nov 2 09:02:12 2008 From: xs at xaph.net (Rafal Kolanski) Date: Sun Nov 2 08:57:22 2008 Subject: [Haskell-cafe] Can't figure out source of race condition when using System.Process Message-ID: <490DB2E4.3090105@xaph.net> Greetings Gentlemen (and Ladies), As part of my small and simple framework for making presentations in Haskell I have a module which, given some text, makes a .tex file and then converts it to .svg for loading into a cairo canvas. It features simple caching (performs md5 on the contents of the .tex file and uses that as the file name... if an .svg by that name exists, it'll get loaded rather than regenerated). Unfortunately, it also segfaults once in a while, probably indicating I have some kind of race condition ... but I can't figure out why. This is the only point in my code that I think I'm using any concurrency, although I'm compiling with ghc --make -threaded. Compiling without -threaded results in a deadlock. Ubuntu 8.10, 64-bit, GHC 6.8.2. Any advice? I'm attaching the module in question (79 lines). Sincerely, Rafal Kolanski. -------------- next part -------------- A non-text attachment was scrubbed... Name: LatexSVG.hs Type: text/x-haskell Size: 2871 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081103/2a2cdb31/LatexSVG.bin From bulat.ziganshin at gmail.com Sun Nov 2 09:48:48 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Nov 2 09:44:26 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: RefSerialize-0.2.1 In-Reply-To: References: Message-ID: <992447070.20081102174848@gmail.com> Hello Alberto, Sunday, November 2, 2008, 5:02:10 PM, you wrote: > Read, Show and Data.Binary do not check for repeated references to > the same data address. afair, SerTH does it, using GHC's internal address compare function what way to check for copies you use? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From briqueabraque at yahoo.com Sun Nov 2 10:13:15 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Sun Nov 2 10:08:24 2008 Subject: [Haskell-cafe] Re: Syntax question: class (Monad m) => MonadReader r m | m -> r where In-Reply-To: <490DAF43.8080901@btinternet.com> References: <490DAF43.8080901@btinternet.com> Message-ID: >> Hi, >> >> I've reading Control.Monad.Reader source code and >> arrived here: >> >> class (Monad m) => MonadReader r m | m -> r where >> >> I can't understand that syntax. Since this is not a >> 'data' line, what is the '|' supposed mean? > > It's called a "functional dependency". This is not part of the > Haskell-98 language standard; check the GHC manual. The documentation says "There should be more documentation, but there isn't (yet). Yell if you need it." :) But I think I was able to understand everything from the examples. Thanks. From bulat.ziganshin at gmail.com Sun Nov 2 10:33:17 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Nov 2 10:38:36 2008 Subject: [Haskell-cafe] Re: Syntax question: class (Monad m) => MonadReader r m | m -> r where In-Reply-To: References: <490DAF43.8080901@btinternet.com> Message-ID: <4954767.20081102183317@gmail.com> Hello Mauricio, Sunday, November 2, 2008, 6:13:15 PM, you wrote: >> It's called a "functional dependency". This is not part of the >> Haskell-98 language standard; check the GHC manual. > The documentation says "There should be more documentation, but there > isn't (yet). Yell if you need it." :) you probably don't found it. since 6.6 (or 6.8?) ghc includes great tutorial on fundeps derived from hugs docs -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Sun Nov 2 10:46:00 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 2 10:41:10 2008 Subject: [Haskell-cafe] ANNOUNCE: zlib and bzlib 0.5 releases Message-ID: <1225640760.8437.189.camel@localhost> I'm pleased to announce updates to the zlib and bzlib packages. The releases are on Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/zlib http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bzlib What's new ========== What's new in these releases is that the extended API is slightly nicer. The simple API that most packages use is unchanged. In particular, these functions have different types: compressWith :: CompressParams -> ByteString -> ByteString decompressWith :: DecompressParams -> ByteString -> ByteString The CompressParams and DecompressParams types are records of compression/decompression parameters. The functions are used like so: compressWith defaultCompressParams { ... } decompressWith defaultDecompressParams { ... } There is also a new parameter to control the size of the first output buffer. This lets applications save memory when they happen to have a good estimate of the output size (some apps like darcs know this exactly). By getting a good estimate and (de)compressing into a single-chunk lazy bytestring this lets apps convert to a strict bytestring with no extra copying cost. Future directions ================= The simple API is very unlikely to change. The current error handling for decompression is not ideal. It just throws exceptions for failures like bad format or unexpected end of stream. This is a tricky area because error streaming behaviour does not mix easily with error handling. On option which I use in the iconv library is to have a data type describe the real error conditions, something like: data DataStream = Chunk Strict.ByteString Checksum DataStream | Error Error -- for some suitable error type | End Checksum With suitable fold functions and functions to convert to a lazy ByteString. Then people who care about error handling and streaming behaviour can use that type directly. For example it should be trivial to convert to an iterator style. People have also asked for a continuation style api to give more control over dynamic behaviour like flushing the compression state (eg in a http server). Unfortunately this does not look easy. The zlib state is mutable and while this can be hidden in a lazy list, it cannot be hidden if we provide access to intermediate continuations. That is because those continuations can be re-run whereas a lazy list evaluates each element at most once (and with suitable internal locking this is even true for SMP). Background ========== The zlib and bzlib packages provide functions for compression and decompression in the gzip, zlib and bzip2 formats. Both provide pure functions on streams of data represented by lazy ByteStrings: compress, decompress :: ByteString -> ByteString This makes it easy to use either in memory or with disk or network IO. For example a simple gzip compression program is just: > import qualified Data.ByteString.Lazy as ByteString > import qualified Codec.Compression.GZip as GZip > > main = ByteString.interact GZip.compress Or you could lazily read in and decompress .gz file using: > content <- GZip.decompress <$> ByteString.readFile file General ======= Both packages are bindings to the corresponding C libs, so they depend on those external C libraries (except on Windows where we build a bundled copy of the C lib source code). The compression speed is as you would expect since it's the C lib that is doing all the work. The zlib package is used in cabal-install to work with .tar.gz files. So it has actually been tested on Windows. It works with all versions of ghc since 6.4 (though it requires Cabal-1.2). The darcs repos for the development versions live on code.haskell.org. I'm very happy to get feedback on the API, the documentation or of course any bug reports. Duncan From bulat.ziganshin at gmail.com Sun Nov 2 11:07:05 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Nov 2 11:02:21 2008 Subject: [Haskell-cafe] ANNOUNCE: zlib and bzlib 0.5 releases In-Reply-To: <1225640760.8437.189.camel@localhost> References: <1225640760.8437.189.camel@localhost> Message-ID: <1893885637.20081102190705@gmail.com> Hello Duncan, Sunday, November 2, 2008, 6:46:00 PM, you wrote: > People have also asked for a continuation style api to give more control > over dynamic behaviour like flushing the compression state (eg in a http > server). Unfortunately this does not look easy. can you gove more details on these? may be i can help -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Sun Nov 2 12:16:54 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 2 12:11:58 2008 Subject: [Haskell-cafe] ANNOUNCE: zlib and bzlib 0.5 releases In-Reply-To: <1893885637.20081102190705@gmail.com> References: <1225640760.8437.189.camel@localhost> <1893885637.20081102190705@gmail.com> Message-ID: <1225646214.8437.212.camel@localhost> On Sun, 2008-11-02 at 19:07 +0300, Bulat Ziganshin wrote: > Hello Duncan, > > Sunday, November 2, 2008, 6:46:00 PM, you wrote: > > > People have also asked for a continuation style api to give more control > > over dynamic behaviour like flushing the compression state (eg in a http > > server). Unfortunately this does not look easy. > > can you gove more details on these? may be i can help For details talk to Johan Tibell Suppose you're trying to work with a strict block IO strategy, like one of these iterator style designs. What kind of api would one want to work with that? The constraint is that for a pure api, the zlib compression state must be used in a single threaded, non-persistent style. Additionally it would be nice to expose the zlib flush feature. This is tricky in a straightforward design because it involves a branching structure of possible operations, and we cannot split the zlib compression state (at least not cheaply). If we could do it persistently we could have something like: data StreamState = OutputAvailable ByteString -- the output buffer StreamState -- next state | InputRequired (ByteString -> StreamState) -- supply input -- or (Flush -> StreamState) -- flush | StreamEnd CheckSum data Flush = FlushEnd | FlushSync | FlushFull initialState :: StreamState But obviously we cannot do this because we have to guarantee the single threaded use of the stream state. Duncan From briqueabraque at yahoo.com Sun Nov 2 12:38:29 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Sun Nov 2 12:33:48 2008 Subject: [Haskell-cafe] Re: Syntax question: class (Monad m) => MonadReader r m | m -> r where In-Reply-To: <4954767.20081102183317@gmail.com> References: <490DAF43.8080901@btinternet.com> <4954767.20081102183317@gmail.com> Message-ID: >>> It's called a "functional dependency". This is not part of the >>> Haskell-98 language standard; check the GHC manual. > >> The documentation says "There should be more documentation, but there >> isn't (yet). Yell if you need it." :) > > you probably don't found it. since 6.6 (or 6.8?) ghc includes great > tutorial on fundeps derived from hugs docs > > It's here, on 'latest' directory: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#functional-dependencies But yes, you're right, there's a lot of good examples and explanations. But that comment is still there, just in the end of the first paragraph. Best, Maur?cio From bos at serpentine.com Sun Nov 2 12:58:47 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sun Nov 2 12:53:47 2008 Subject: [Haskell-cafe] Can't figure out source of race condition when using System.Process In-Reply-To: <490DB2E4.3090105@xaph.net> References: <490DB2E4.3090105@xaph.net> Message-ID: 2008/11/2 Rafal Kolanski > > Unfortunately, it also segfaults once in a while, probably indicating I > have some kind of race condition ... but I can't figure out why. What is the "it" that segfaults? The Haskell program shouldn't, at least. That said, your code for reading from child processes is wrong. You should read all of a child's output strictly (i.e. hGetContents alone will not do the trick) before you wait for its exit status. Your current scheme reverses this order, and there is hence no guarantee that it will read anything from the defunct child process. There's some possibility that this might be the cause of your segfault, which to me would suggest the presence of a bug in the runtime system. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081102/4c0679e7/attachment.htm From bertram.felgenhauer at googlemail.com Sun Nov 2 12:59:58 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sun Nov 2 12:55:03 2008 Subject: [Haskell-cafe] Array bug? In-Reply-To: <490C6E9E.9060703@btinternet.com> References: <490C513A.3030200@btinternet.com> <20081101141430.GA4203@zombie.inf.tu-dresden.de> <490C6E9E.9060703@btinternet.com> Message-ID: <20081102175958.GA4564@zombie.inf.tu-dresden.de> Andrew Coppin wrote: > Bertram Felgenhauer wrote: >> Yes, it's a known bug - a conscious choice really. See >> >> http://hackage.haskell.org/trac/ghc/ticket/2120 >> >> It's somewhat ironic that this behaviour was introduced by a patch >> that made arrays safer to use in other respects. > > ...so it's *not* going to be fixed then? It's not going to be fixed by itself - the first comment for the bug report basically asks interested parties to submit a proposal for changing this. Bertram From mad.one at gmail.com Sun Nov 2 13:44:49 2008 From: mad.one at gmail.com (Austin Seipp) Date: Sun Nov 2 13:39:51 2008 Subject: [Haskell-cafe] Re: Syntax question: class (Monad m) => MonadReader r m | m -> r where In-Reply-To: References: <490DAF43.8080901@btinternet.com> Message-ID: <1225646607-sup-5051@existential.local> This message is literate haskell. > {-# LANGUAGE FunctionalDependencies, MultiParamTypeClasses #-} > {-# LANGUAGE TypeFamilies, EmptyDataDecls, FlexibleContexts #-} Just to add on for people watching, a fundep pretty much just says that if: > class Foo a b | a -> b where > bar :: a -> b > baz :: b -> a Then if you have an instance: > data A -- we hold types abstract for simplicity > data B > data C > > u = undefined -- convenience > > instance Foo A B where > bar x = u > baz y = u Then there can be no other instance for the class Foo of the form 'A x' where x /= B, e.g. it would be invalid to then have: > -- uncommenting this will error: > -- instance Foo A C where > -- bar x = u > -- baz y = u Why? We have established in the class declaration that 'a' determines 'b' and in an actual instance of that class (concretely) stated that in this case, the type A determines the type B and that relation holds true for any usage of the class (in something like a constraint.) The only way the typechecker can resolve that /relation/ is if (roughly speaking I think) the set of types that can be of type 'b' given an already known type 'a' are constrained in some way. If you do not have the fundep, then the class will work and so will instances, but you will get ambiguous type errs when trying to use functions of the type class. > class Foo2 a b where > foobar :: a -> b > foobaz :: b -> a In the usage of 'foobar,' with no functional dependency, the compiler cannot determine the type 'b' because in the instances of of 'Foo' we do not 'bind' types together in any way, so for any instance of 'Foo A x' an x could work here: > instance Foo2 Bool Int where > foobar x = u > foobaz y = u > instance Foo2 Bool Char where > foobar x = u > foobaz y = u > This instance will compile, but attempting to use it does not: $ ghci ... GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( fundeps-assoc.lhs, interpreted ) Ok, modules loaded: Main. *Main> :t foobar foobar :: (Foo2 a b) => a -> b *Main> let z = foobar True :1:8: No instance for (Foo2 Bool b) arising from a use of `foobar' at :1:8-18 Possible fix: add an instance declaration for (Foo2 Bool b) In the expression: foobar True In the definition of `z': z = foobar True *Main> The compiler is not able to determine what to declare the result type of 'foobar True' as, since there is both an instance of 'Foo2 Bool' for multiple types! However, in the original Foo class we do have a fundep, and so we know that if we give 'bar' a value of type 'A' then we get a 'B' in return - hence, the fundep is a relation and constrains the possible values of the type variable 'b' in the declaration, so the compiler can figure this out. *Main> let z = bar (u::A) *Main> :t z z :: B *Main> Functional dependencies are a little tricky, but they can basically set up relations between types however you want to (for example, using a fundep of 'a -> b, b -> a' specifies a 1-to-1 correlation between the types which instantiate 'a' and 'b'.) However, there is an alternative which I think is far easier to grok and can express the same 'set of equations' - associated types. I think they are nicer mainly because they make the connections between types in a /functional/ way, not a relational one (despite the name of functional dependencies.) For instance, the Foo class above could be rewritten as: > class (Show a, Show (Boom a), Eq (Boom a)) => Foo3 a where > type Boom a :: * > barfoo :: a -> Boom a > bazfoo :: Boom a -> a This states that along with method declarations for an instance we must also specify a type declaration - 'Boom' is an associated type synonym that takes one type a, and the overall kind of 'Boom a' is * (that is, it is a 'fully satured' type.) The functional part is seen in the instance. > instance Foo3 Bool where > type Boom Bool = Int > barfoo x = 10 > bazfoo y = u So we can see 'Boom' as a function at the type level, indexed by types. *Main> let z = barfoo True *Main> :t z z :: Boom Bool *Main> print (z::Int) 10 *Main> In this case evaluation is undefined but we can see that the equation overall results in a type of 'Int' as the typechecker can unify the types 'Boom Bool' and Int, even though we have to explicitly type it. For an even better example, I think the type-vector trick is pretty cute too (uses GADTs): http://thoughtpolice.stringsandints.com/code/haskell/misc/type-vectors.hs This message is getting somewhat long but, I hope that's an adequate explanation for those who might be hazy or interested. For more on associated types you should probably look here: http://haskell.org/haskellwiki/GHC/Indexed_types#An_associated_type_synonym_example Austin From andrewcoppin at btinternet.com Sun Nov 2 13:53:24 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun Nov 2 13:48:18 2008 Subject: [Haskell-cafe] Array bug? In-Reply-To: <20081102175958.GA4564@zombie.inf.tu-dresden.de> References: <490C513A.3030200@btinternet.com> <20081101141430.GA4203@zombie.inf.tu-dresden.de> <490C6E9E.9060703@btinternet.com> <20081102175958.GA4564@zombie.inf.tu-dresden.de> Message-ID: <490DF724.3090903@btinternet.com> Bertram Felgenhauer wrote: > Andrew Coppin wrote: > >> Bertram Felgenhauer wrote: >> >>> Yes, it's a known bug - a conscious choice really. See >>> >>> http://hackage.haskell.org/trac/ghc/ticket/2120 >>> >>> It's somewhat ironic that this behaviour was introduced by a patch >>> that made arrays safer to use in other respects. >>> >> ...so it's *not* going to be fixed then? >> > > It's not going to be fixed by itself - the first comment for the > bug report basically asks interested parties to submit a proposal > for changing this. > Well I certainly don't have the skill to fix it. (Presumably all that array stuff is hard-wired into the compiler.) In my opinion, what we should have is 1. An interface that is guaranteed-safe, no matter how inefficient that is. 2. An interface that is guaranteed-efficient, no matter how unsafe that is. 3. It should be extremely easy to switch from one to the other. You write your code against the safe interface, test it until you're happy with it, and then switch to the fast interface. Currently, the "safe" interface actually allows out-of-bounds indicies (in a way which reveals the underlying implementation), and the "fast" interface isn't publicly supported. Both of these things should be changed. From t.r.willingham at gmail.com Sun Nov 2 14:10:43 2008 From: t.r.willingham at gmail.com (T Willingham) Date: Sun Nov 2 14:05:43 2008 Subject: [Haskell-cafe] Memory efficiency questions for real-time graphics In-Reply-To: <3d96ac180811011211j2d4bf128q42c9e606bf9cf0d7@mail.gmail.com> References: <9c72296b0810271903s31e9cf65y9818caf189ebd7ef@mail.gmail.com> <3d96ac180810281224h69dc0fb7m2a84882bdecafa7c@mail.gmail.com> <9c72296b0811011157ke3b6815o7a69653efd8cca92@mail.gmail.com> <3d96ac180811011211j2d4bf128q42c9e606bf9cf0d7@mail.gmail.com> Message-ID: <9c72296b0811021110n3b4b5377hd64217052ce62d3c@mail.gmail.com> On Sat, Nov 1, 2008 at 2:11 PM, Sebastian Sylvan wrote: > On Sat, Nov 1, 2008 at 6:57 PM, T Willingham >> >> The per-vertex computation is a quite complex time-dependent function >> applied to the given domain on each update. Yet even if it were >> simple, I would still first implement the formulas in Haskell and >> leave the optimization for later, if at all. > > I'd be very surprised to see a vertex transform that would be faster to > implement on the CPU than the GPU. It appears you misunderstood "complex time-dependent function". This is quite a bit of Haskell code involving a significant amount of octonion algebra. It could, in principle, be put on the GPU, however that should be the very last step after everything else works. > There are various ways of writing out your vertex data too, so if it doesn't > change too often you can still do the transformation on the GPU, As I previously stated, it changes every frame. Take a highly complicated function and apply it to N vertices. Now increase N until the framerate is affected. That is where I am. It is obvious that any N-sized allocations will cause the framerate to stutter. This is not just theoretical: I *see* it as I increase N while it's running. This is the point of my initial email, the subject of which is memory efficiency. From dons at galois.com Sun Nov 2 14:13:07 2008 From: dons at galois.com (Don Stewart) Date: Sun Nov 2 14:07:50 2008 Subject: [Haskell-cafe] Memory efficiency questions for real-time graphics In-Reply-To: <9c72296b0811021110n3b4b5377hd64217052ce62d3c@mail.gmail.com> References: <9c72296b0810271903s31e9cf65y9818caf189ebd7ef@mail.gmail.com> <3d96ac180810281224h69dc0fb7m2a84882bdecafa7c@mail.gmail.com> <9c72296b0811011157ke3b6815o7a69653efd8cca92@mail.gmail.com> <3d96ac180811011211j2d4bf128q42c9e606bf9cf0d7@mail.gmail.com> <9c72296b0811021110n3b4b5377hd64217052ce62d3c@mail.gmail.com> Message-ID: <20081102191307.GA19981@scytale.galois.com> t.r.willingham: > On Sat, Nov 1, 2008 at 2:11 PM, Sebastian Sylvan > wrote: > > On Sat, Nov 1, 2008 at 6:57 PM, T Willingham > >> > >> The per-vertex computation is a quite complex time-dependent function > >> applied to the given domain on each update. Yet even if it were > >> simple, I would still first implement the formulas in Haskell and > >> leave the optimization for later, if at all. > > > > I'd be very surprised to see a vertex transform that would be faster to > > implement on the CPU than the GPU. > > It appears you misunderstood "complex time-dependent function". This > is quite a bit of Haskell code involving a significant amount of > octonion algebra. It could, in principle, be put on the GPU, however > that should be the very last step after everything else works. > > > There are various ways of writing out your vertex data too, so if it doesn't > > change too often you can still do the transformation on the GPU, > > As I previously stated, it changes every frame. > > Take a highly complicated function and apply it to N vertices. Now > increase N until the framerate is affected. That is where I am. It > is obvious that any N-sized allocations will cause the framerate to > stutter. This is not just theoretical: I *see* it as I increase N > while it's running. This is the point of my initial email, the > subject of which is memory efficiency. I'm glad things are going well. Do you have the code somewhere for review? -- Don From wren at freegeek.org Sun Nov 2 14:23:57 2008 From: wren at freegeek.org (wren ng thornton) Date: Sun Nov 2 14:18:56 2008 Subject: [Haskell-cafe] number of references to a variable In-Reply-To: <490C9833.4000704@btinternet.com> References: <490C5BE0.1090300@btinternet.com> <919CCB0A-D31C-4407-ACFB-67C8651931D3@alum.mit.edu> <490C9833.4000704@btinternet.com> Message-ID: <490DFE4D.2070101@freegeek.org> Andrew Coppin wrote: > Jan-Willem Maessen wrote: > > Usually the clever thing you want to know is "this is the sole > > reference to the pointed-to object". > > Does GHC have weak references? (I seem to recall it does...) http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-Weak.html As for the uniqueness of a reference to an object, there are alternatives to reference-counting techniques. For example, the language Clean[1] builds it into the type system (to replace monads) and they've gotten very good performance results from doing so. There are other linear logic approaches as well, though porting any of these to Haskell would take a fair deal of work to make efficient. Certainly a worthy research goal, but probably not what you had in mind :) [1] -- Live well, ~wren From simon.clarkstone at gmail.com Sun Nov 2 14:34:02 2008 From: simon.clarkstone at gmail.com (Simon Richard Clarkstone) Date: Sun Nov 2 14:29:25 2008 Subject: [Haskell-cafe] Re: is there a way to pretty print a module? In-Reply-To: References: <20081030091551.513c73ee@solaris> Message-ID: <490E00AA.20902@gmail.com> Anatoly Yakovenko wrote: >>> is there a way to pretty print a module? >>> like: >>> >>> module Main where >>> import Language.Haskell.TH >>> main = do >>> print $ pprint Main >>> >> haskell-src should be able to do that. > > I think haskell-src requires you to read the module at run time. I > want to embed the contents of the module in my program. Basically a > program that can print itself. This is rather like the idea of a quine; a program the prints itself out without referring directly to its own source code. The usual Haskell quine is: putStrLn$(\s->s++show s)"putStrLn$(\\s->s++show s)" If merely returning the source code is enough then you can do: (\s->s++show s)"(\\s->s++show s)" It could be more elegant if \ weren't both lambda and string escape. -- src/ From Juliusz.Chroboczek at pps.jussieu.fr Sun Nov 2 14:45:43 2008 From: Juliusz.Chroboczek at pps.jussieu.fr (Juliusz Chroboczek) Date: Sun Nov 2 14:41:01 2008 Subject: [Haskell-cafe] Re: [darcs-users] Poll: Do you need to be able to build darcs from source on GHC 6.6? In-Reply-To: (Jason Dagit's message of "Thu\, 30 Oct 2008 15\:00\:50 -0700") References: <117f2cc80810280832r1a0d3fdeke5020e549b0c1405@mail.gmail.com> <7iskqg70du.fsf@lanthane.pps.jussieu.fr> <7iprlhal88.fsf@lanthane.pps.jussieu.fr> Message-ID: <7i8ws152u0.fsf@lanthane.pps.jussieu.fr> > I see. If you're using the darcs 1 binary I would encourage you to > upgrade. If you meant darcs 1 repository format then I would > encourage you to consider darcs 1 hashed repository format. You don't > even have to upgrade the public facing repo. Just 'darcs get --hashed > ...'. I mean that I'm currently using Debian's 1.0.3 on my stable servers, and the old repository format all over the place. I'm using 2.0.2 on my desktop machines. I will definitely switch to the Darcs 2 implementation at some point, but Darcs 1 hasn't broken down yet, and I've got other stuff to do right now. >> The alternative is to build a static version of Darcs that I can install on >> my stable (soon to be oldstable) servers. That might actually be the simplest solution, now I come to think about it. >> The alternative to both alternatives is to switch to git. > Right. But I hope you're not saying that because you find this thread > upsetting. No. That was just a way of pointing out that other revision control systems do not have such complex build dependencies. Juliusz From derek.a.elkins at gmail.com Sun Nov 2 14:58:35 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sun Nov 2 14:53:44 2008 Subject: [Haskell-cafe] Re: is there a way to pretty print a module? In-Reply-To: <490E00AA.20902@gmail.com> References: <20081030091551.513c73ee@solaris> <490E00AA.20902@gmail.com> Message-ID: <1225655915.23780.0.camel@derek-laptop> On Sun, 2008-11-02 at 19:34 +0000, Simon Richard Clarkstone wrote: > Anatoly Yakovenko wrote: > >>> is there a way to pretty print a module? > >>> like: > >>> > >>> module Main where > >>> import Language.Haskell.TH > >>> main = do > >>> print $ pprint Main > >>> > >> haskell-src should be able to do that. > > > > I think haskell-src requires you to read the module at run time. I > > want to embed the contents of the module in my program. Basically a > > program that can print itself. > > This is rather like the idea of a quine; a program the prints itself out > without referring directly to its own source code. The usual Haskell > quine is: > > putStrLn$(\s->s++show s)"putStrLn$(\\s->s++show s)" > > If merely returning the source code is enough then you can do: > > (\s->s++show s)"(\\s->s++show s)" > > It could be more elegant if \ weren't both lambda and string escape. So get rid of the lambda, ap(++)show"ap(++)show" From wren at freegeek.org Sun Nov 2 15:06:31 2008 From: wren at freegeek.org (wren ng thornton) Date: Sun Nov 2 15:01:30 2008 Subject: [Haskell-cafe] number of references to a variable In-Reply-To: References: <490C5BE0.1090300@btinternet.com> <919CCB0A-D31C-4407-ACFB-67C8651931D3@alum.mit.edu> <490C9833.4000704@btinternet.com> <490DFE4D.2070101@freegeek.org> Message-ID: <490E0847.4020102@freegeek.org> Alberto G. Corona wrote: > * "Certainly a worthy research goal, but probably not what you had in mind > :)" > > *Not at all, My interest on that was on to improve RefSerialize. Although > the Clean people has done a superb job on optimization. By the way, I'm not > sure if uniqueness is the cause of his performance. I tested Haskell code > generated using Maybe with and without monad instance and the monad does not > impose any overhead at all. Oh, I wasn't saying that monads impose any overhead. Rather, the Clean folks aren't fans of monads and so they use uniqueness typing in order to provide the same kind of solution to IO while retaining functional purity. GHC's implementation of IO is actually very similar under the hood to what Clean does, though that's not necessarily true of other monads. Even though they seem to intersect at IO, the ideas of monads and linear logics are orthogonal. The big optimization trick with linear logic is, since you know when some object is uniquely referenced, you know when it's safe to destructively update it in situ. For example, you can reverse a spine-unique list in linear time with zero space (modulo registers) by just inverting the spine pointers as you traverse it. Since it's uniquely referenced, noone else will notice so referential transparency is preserved. Doing it this way saves on allocation costs and on garbage collection. There are certainly other ways to use the information that some object is held only by a single reference, but Clean's optimizations are the first that leap to my mind. -- Live well, ~wren From marco-oweber at gmx.de Sun Nov 2 15:15:25 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Nov 2 15:10:25 2008 Subject: [Haskell-cafe] Can't figure out source of race condition when using System.Process In-Reply-To: <490DB2E4.3090105@xaph.net> References: <490DB2E4.3090105@xaph.net> Message-ID: <20081102201525.GB21990@gmx.de> On Mon, Nov 03, 2008 at 01:02:12AM +1100, Rafal Kolanski wrote: > Rafal Kolanski. > -- Pass text to md5sum and drop the final " -" when returning > hashMD5 text = do > (inp,out,err,pid) <- runInteractiveProcess "md5sum" [] Nothing Nothing > forkIO $ do > hPutStrLn inp text > hClose inp > exit <- waitForProcess pid > case exit of ExitFailure _ -> error "md5sum fail" > _ -> return () > [...] Why do you use forkIO here? It's not necessary. The process will run in background on its own. ? It would help me tracking the problem down having a full compilable example.. Sincerly Marc Weber From barsoap at web.de Sun Nov 2 15:25:47 2008 From: barsoap at web.de (Achim Schneider) Date: Sun Nov 2 15:25:05 2008 Subject: [Haskell-cafe] Re: Poll: Do you need to be able to build darcs from source on GHC 6.6? References: <117f2cc80810280832r1a0d3fdeke5020e549b0c1405@mail.gmail.com> <7iskqg70du.fsf@lanthane.pps.jussieu.fr> <7iprlhal88.fsf@lanthane.pps.jussieu.fr> <7i8ws152u0.fsf@lanthane.pps.jussieu.fr> Message-ID: <20081102212547.7f299496@solaris> Juliusz Chroboczek wrote: > No. That was just a way of pointing out that other revision control > systems do not have such complex build dependencies. *cough* % export USE="doc gtk iconv perl subversion bash-completion cgi curl cvs emacs mozsha1 ppcsha1 threads tk vim-syntax webdav xinetd" % emerge git --emptytree -p |wc -l 381 % export USE="-doc gtk iconv perl subversion bash-completion cgi curl cvs emacs mozsha1 ppcsha1 threads tk vim-syntax webdav xinetd" % emerge git --emptytree -p |wc -l 329 % export USE="-doc -gtk -iconv -perl -subversion -bash-completion -cgi -curl -cvs -emacs -mozsha1 -ppcsha1 -threads -tk -vim-syntax -webdav -xinetd" emerge git --emptytree -p |wc -l % emerge git --emptytree -p |wc -l 57 % USE=doc emerge darcs --emptytree -p | wc -l 329 (that's mostly because stuff like latex pulls the whole of x11 and gtk with my current settings... I can't be arsed to figure all of that out right now) % USE=-doc emerge darcs --emptytree -p | wc -l 79 Now you can say that "A severely crippled version of git has less source dependencies", but don't ever claim that the build dependencies are less _complex_. 17 package-specific use flags are rather extreme. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From droundy at darcs.net Sun Nov 2 16:01:14 2008 From: droundy at darcs.net (David Roundy) Date: Sun Nov 2 15:55:41 2008 Subject: [Haskell-cafe] Can't figure out source of race condition when using System.Process In-Reply-To: <20081102201525.GB21990@gmx.de> References: <490DB2E4.3090105@xaph.net> <20081102201525.GB21990@gmx.de> Message-ID: <20081102210113.GC7406@darcs.net> On Sun, Nov 02, 2008 at 09:15:25PM +0100, Marc Weber wrote: > On Mon, Nov 03, 2008 at 01:02:12AM +1100, Rafal Kolanski wrote: > > Rafal Kolanski. > > -- Pass text to md5sum and drop the final " -" when returning > > hashMD5 text = do > > (inp,out,err,pid) <- runInteractiveProcess "md5sum" [] Nothing Nothing > > forkIO $ do > > hPutStrLn inp text > > hClose inp > > exit <- waitForProcess pid > > case exit of ExitFailure _ -> error "md5sum fail" > > _ -> return () > > [...] > > Why do you use forkIO here? It's not necessary. The process will run in > background on its own. ? It looks to me like this code requires a forkIO, not in the writing to inp, but rather in the reading of out and err. Otherwise, those buffers may fill up and your process will hang... -- David Roundy http://www.darcs.net From t.r.willingham at gmail.com Sun Nov 2 16:23:38 2008 From: t.r.willingham at gmail.com (T Willingham) Date: Sun Nov 2 16:18:36 2008 Subject: [Haskell-cafe] Memory efficiency questions for real-time graphics In-Reply-To: <20081102191307.GA19981@scytale.galois.com> References: <9c72296b0810271903s31e9cf65y9818caf189ebd7ef@mail.gmail.com> <3d96ac180810281224h69dc0fb7m2a84882bdecafa7c@mail.gmail.com> <9c72296b0811011157ke3b6815o7a69653efd8cca92@mail.gmail.com> <3d96ac180811011211j2d4bf128q42c9e606bf9cf0d7@mail.gmail.com> <9c72296b0811021110n3b4b5377hd64217052ce62d3c@mail.gmail.com> <20081102191307.GA19981@scytale.galois.com> Message-ID: <9c72296b0811021323h78c256banc7140a0daca64feb@mail.gmail.com> On Sun, Nov 2, 2008 at 2:13 PM, Don Stewart wrote: > t.r.willingham: >> Take a highly complicated function and apply it to N vertices. Now >> increase N until the framerate is affected. That is where I am. It >> is obvious that any N-sized allocations will cause the framerate to >> stutter. This is not just theoretical: I *see* it as I increase N >> while it's running. This is the point of my initial email, the >> subject of which is memory efficiency. > > I'm glad things are going well. Do you have the code somewhere for > review? If you read my initial post, you'll see that I am looking to convert an existing C++ application to Haskell. Above I am describing the current C++ implementation. From lemming at henning-thielemann.de Sun Nov 2 16:40:57 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Nov 2 16:35:58 2008 Subject: [Haskell-cafe] ANNOUNCE: zlib and bzlib 0.5 releases In-Reply-To: <1225640760.8437.189.camel@localhost> References: <1225640760.8437.189.camel@localhost> Message-ID: On Sun, 2 Nov 2008, Duncan Coutts wrote: > The current error handling for decompression is not ideal. It just > throws exceptions for failures like bad format or unexpected end of > stream. This is a tricky area because error streaming behaviour does not > mix easily with error handling. Maybe http://hackage.haskell.org/packages/archive/explicit-exception/0.0.1/doc/html/Control-Monad-Exception-Asynchronous.html can be of help? From t.r.willingham at gmail.com Sun Nov 2 18:28:08 2008 From: t.r.willingham at gmail.com (T Willingham) Date: Sun Nov 2 18:23:06 2008 Subject: [Haskell-cafe] Automatic parallelism in Haskell, similar to "make -j4"? Message-ID: <9c72296b0811021528w596e07b4pbd8ed46cdd7ef6c6@mail.gmail.com> I was surprised when I read the multi-core section of Real World Haskell which explains the use of par, seq, and force to achieve parallelism. While it's obvious a programmer could provide useful parallelism hints to the compiler, given the nature of the language I would have thought Haskell could do a significant amount of parallelism itself without any hints or code changes at all. I am thinking of our troglodytic friend 'make', which will run (for example) 4 parallel jobs when given the option "make -j4". Even 'rake', the ruby version of make, now has a branch (called drake) which does the parallel -j option. Since much of Haskell code is free of side effects, it would seem that it can be analyzed in similar manner to Makefile dependencies in order to find sections which can be run in parallel. What would it take to implement a -j equivalent for, say, GHC? Or if this is not possible, what is wrong with my reasoning? Thanks, TW From bulat.ziganshin at gmail.com Sun Nov 2 18:44:40 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Nov 2 18:39:57 2008 Subject: [Haskell-cafe] Automatic parallelism in Haskell, similar to "make -j4"? In-Reply-To: <9c72296b0811021528w596e07b4pbd8ed46cdd7ef6c6@mail.gmail.com> References: <9c72296b0811021528w596e07b4pbd8ed46cdd7ef6c6@mail.gmail.com> Message-ID: <1358228143.20081103024440@gmail.com> Hello T, Monday, November 3, 2008, 2:28:08 AM, you wrote: > What would it take to implement a -j equivalent for, say, GHC? Or if > this is not possible, what is wrong with my reasoning? problem is that make have rather large pices of work which it can run parallel. if ghc will try to parallel every machine operation, it will pend more time maintaining these jobs. 'par' is just the way to tell GHC "this part of job is large enough" -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From t.r.willingham at gmail.com Sun Nov 2 19:42:49 2008 From: t.r.willingham at gmail.com (T Willingham) Date: Sun Nov 2 19:37:47 2008 Subject: [Haskell-cafe] Automatic parallelism in Haskell, similar to "make -j4"? In-Reply-To: <1358228143.20081103024440@gmail.com> References: <9c72296b0811021528w596e07b4pbd8ed46cdd7ef6c6@mail.gmail.com> <1358228143.20081103024440@gmail.com> Message-ID: <9c72296b0811021642s7b65633fq795f0208d3a77746@mail.gmail.com> On Sun, Nov 2, 2008 at 6:44 PM, Bulat Ziganshin wrote: >> What would it take to implement a -j equivalent for, say, GHC? Or if >> this is not possible, what is wrong with my reasoning? > > problem is that make have rather large pices of work which it can run > parallel. if ghc will try to parallel every machine operation, it will > pend more time maintaining these jobs. 'par' is just the way to tell > GHC "this part of job is large enough" Right, but couldn't the Haskell complier+runtime discover "rather large pieces of work"? From dons at galois.com Sun Nov 2 19:48:39 2008 From: dons at galois.com (Don Stewart) Date: Sun Nov 2 19:43:19 2008 Subject: [Haskell-cafe] Automatic parallelism in Haskell, similar to "make -j4"? In-Reply-To: <9c72296b0811021642s7b65633fq795f0208d3a77746@mail.gmail.com> References: <9c72296b0811021528w596e07b4pbd8ed46cdd7ef6c6@mail.gmail.com> <1358228143.20081103024440@gmail.com> <9c72296b0811021642s7b65633fq795f0208d3a77746@mail.gmail.com> Message-ID: <20081103004839.GC20216@scytale.galois.com> t.r.willingham: > On Sun, Nov 2, 2008 at 6:44 PM, Bulat Ziganshin > wrote: > >> What would it take to implement a -j equivalent for, say, GHC? Or if > >> this is not possible, what is wrong with my reasoning? > > > > problem is that make have rather large pices of work which it can run > > parallel. if ghc will try to parallel every machine operation, it will > > pend more time maintaining these jobs. 'par' is just the way to tell > > GHC "this part of job is large enough" > > Right, but couldn't the Haskell complier+runtime discover "rather > large pieces of work"? Requires runtime profiling to work out the costs. See this paper which implements this this idea, PDF http://research.microsoft.com/~tharris/papers/2007-fdip.pdf HTML http://209.85.173.104/search?q=cache:7cC4fQjCEH4J:research.microsoft.com/~tharris/papers/2007-fdip.pdf Note that for subsets of Haskell, where we have more information statically about the costs involves, we can do the parallelism automatically. Data Parallel Haskell is the prime example. -- Don From lrpalmer at gmail.com Sun Nov 2 19:48:27 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun Nov 2 19:43:27 2008 Subject: [Haskell-cafe] Automatic parallelism in Haskell, similar to "make -j4"? In-Reply-To: <9c72296b0811021642s7b65633fq795f0208d3a77746@mail.gmail.com> References: <9c72296b0811021528w596e07b4pbd8ed46cdd7ef6c6@mail.gmail.com> <1358228143.20081103024440@gmail.com> <9c72296b0811021642s7b65633fq795f0208d3a77746@mail.gmail.com> Message-ID: <7ca3f0160811021648r58aa061bv5c82299cb9d4f6a6@mail.gmail.com> On Sun, Nov 2, 2008 at 12:42 PM, T Willingham wrote: > On Sun, Nov 2, 2008 at 6:44 PM, Bulat Ziganshin > wrote: >>> What would it take to implement a -j equivalent for, say, GHC? Or if >>> this is not possible, what is wrong with my reasoning? >> >> problem is that make have rather large pices of work which it can run >> parallel. if ghc will try to parallel every machine operation, it will >> pend more time maintaining these jobs. 'par' is just the way to tell >> GHC "this part of job is large enough" > > Right, but couldn't the Haskell complier+runtime discover "rather > large pieces of work"? Perhaps, but not easily. Especially if it can be done statically, there is plenty of research to be done in this area. Haskell is rather different from make. The graph of a lambda calculus program is not nearly as transparent as the graph of a makefile -- *especially* considering lazy evaluation. For example, you might think: map (+1) [1..10000000] Is a "rather large piece of work", but if it is then applied to "take 4", that is no longer true. We don't want to be futilely spinning our processor computing this. So my guess is that there are some cases, in the same way as strictness analysis, where you can identify these, but there are many cases which are much more subtle and hard to identify automatically. But I am no expert in the area. Luke From briqueabraque at yahoo.com Sun Nov 2 20:43:26 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Sun Nov 2 20:38:36 2008 Subject: [Haskell-cafe] Making 'community' server our social network Message-ID: Hi, I've beeing doing something with darcs that is so great that, although I'm sure a lot of people are already doing the same, I think it would be nice to share with you. I did 'cd ~' and then: darcs initialize darcs add .emacs darcs add .xmonad/xmonad.hs darcs add .inputrc ... etc. So I'm using darcs to keep track of all my configuration files, and now I don't need to care about reinstalling the OS, changing machines from office to home, changing configurations and then realizing it was a mistake etc. Then I thought community.haskell.org could offer a default darcs repositories for all users named after their owners. For instance, if you want to check my personal files you would do: darcs get http://code.haskell.org/MauricioAntunes That would allow us not only to share our configuration, but also share all those small files that are not "professional" enough to became projects for their own, but that are nevertheless interesting since we put our good ideas there: scripts to start our favorite software or do system maintenance; small Haskell utilities to do some cool math or science trick, stress some language feature or download our standard music collection from the web; a list of favorite sites and a related completion script so we can list then in 'dmenu' completion; etc. etc. etc. The next bonus step would be to get a list at all users default repository main page of all other users they have granted write access to some of their projects. Then we would be able to navigate throw linked lists of people with related interests and needs. I think we need no more to get what will be MySpace, Facebook or something else for text-driven people. And then, of course, world domination. Although I don't really imagine any business model around that :) Best, Maur?cio From nunofaurbiz at yahoo.com Sun Nov 2 22:18:12 2008 From: nunofaurbiz at yahoo.com (Nun Aurbiz) Date: Sun Nov 2 22:19:49 2008 Subject: [Haskell-cafe] a minimal Windows program in Haskell? Message-ID: <220034.92058.qm@web57402.mail.re1.yahoo.com> How do I make a minimal Windows application in Haskell? I know there are Win API bindings in the libraries, and of course the ffi lets you call into and out of C, but I have no sense of how to bring it all together. I can't find any samples either. Is the Haskell code the "main" application and you just ffi into the Win API? Or does it ffi into a win_main.c that I write? Or is the win_main.c the "main" application and it calls into Haskell? Here is what I am talking about by a "minimal Windows application" (written in psuedo C code). #define WIN32_LEAN_AND_MEAN #include LRESULT CALLBACK windowsProcedure(..) { switch(message) { case WM_CLOSE: PostQuitMessage(0); return 0; } return DefWindowProc(..); } int APIENTRY WinMain(..){ WNDCLASS window_class; RegisterClass(&window_class) window = CreateWindow(..); ShowWindow(..); while(true) { /* do whatever */ while(PeekMessage(..)) if(msg.message == WM_QUIT) return msg.wParam; else DispatchMessage(&msg); } return 0; } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081102/792cc459/attachment.htm From ivan.miljenovic at gmail.com Sun Nov 2 22:35:58 2008 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Sun Nov 2 22:31:05 2008 Subject: [Haskell-cafe] ANNOUNCE: Graphalyze-0.5 and SourceGraph-0.3 Message-ID: <20081103133558.5512b2d9@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've just submitted my thesis this morning (w00t!!!) and as such I'm announcing the latest versions of Graphalyze [1,2] and SourceGraph [3,4], which fix a couple of bugs in the previous versions (these bugs were fixed whilst waiting for my supervisor to finish reading through my draft, and as such I had to re-write bits of my thesis that talked about the limitations of the software :s ). [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Graphalyze [2] http://code.haskell.org/Graphalyze [3] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SourceGraph [4] http://code.haskell.org/SourceGraph Briefly, SourceGraph is a utility that uses the Graphalyze library to analyse Cabalized Haskell software. Its input/output is rather restrictive at the moment: it takes a single argument, which is the path to a .cabal file, and then produces an HTML report in: /SourceGraph/.html This report contains visualisation of the code for each module, for the imports (similar to what graphmod [5] does) as well as the entire code base. Furthermore, the entire code base is also visualised with functions grouped by the modules they're defined in, as well some simple analyses (such as comparing the export list to what functions are actually roots, similar to the output for top-level functions returned by GHC when using -fwarn-unused-binds). Main changes in Graphalyze since version 0.4: * When writing my thesis, I found some obvious silly mistakes (such as copying the rootsOf function definition to leavesOf, but not changing the function definition). * Images in the document representation are now inline elements. * When using Pandoc [6] for document generation, the size of generated graphs is now customisable on a per-format basis; furthermore, for web pages graph visualisations link to larger versions. Also, graph visualisations can now be created in a sub-directory. Main changes in SourceGraph since version 0.2: * Now uses Cabal 1.6 * Improve visual layout of generated HTML report (still no CSS though). * "Smarter" analysis: don't show trivial analysis results, and when analysing the entire code base don't return cliques, etc. that contain functions all in the same module (as they would have been reported in the per-module section). Note, however, that the parsing limitations for version 0.2 still apply: cpp is still as-yet unsupported (as I'm not sure what I'll do about choosing cpp flags); Template Haskell, HaRP and HXML are still ignored and functions in class declarations/records are still ignored (the former because it's ambiguous which actual function you want, the latter because they're boring :p ). Also, SourceGraph is _still_ not a refactoring tool ;-) If anyone's interested, I'll soon be uploading the final version of my thesis to my blog. Also, if anyone is interested in hacking on any of this, feel free! I'll probably leave it for a while (I'm going to be doing Java coding over summer, blech :s ), but I intend to come back to it later on. - -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkOcaAACgkQfEfFJ9JhvyjhIwCeM9VXsJeSVK2CdWURJDer6zoA A5YAoIfayHtjpw0qt/gyPZhhhypOwzSh =x+/X -----END PGP SIGNATURE----- From ivan.miljenovic at gmail.com Sun Nov 2 22:46:30 2008 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Sun Nov 2 22:41:36 2008 Subject: [Haskell-cafe] ANNOUNCE: Graphalyze-0.5 and SourceGraph-0.3 In-Reply-To: References: <20081103133558.5512b2d9@gmail.com> Message-ID: <20081103134630.60dabf75@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 2 Nov 2008 22:43:27 -0500 "Gwern Branwen" wrote: > Darn! I was really hoping to analyze my XMonadContrib modules which use > CPP. :( > > Come now, is it really so intractable? Why not try a dumb, but simple > and understandable approach - like dropping everything inside CPP > sections, and analysing the remainder? If it's clearly stated in the > docs, I don't think any user could really blame you. If they insist, > you could always add a flag like --strict-cpp ('So you prefer no > results to somewhat wrong results? FINE.') The main reason I haven't is due to lack of time... as it was, these last few fix-ups were only done last-minute whilst I was waiting for my supervisor to read through my draft (and mainly fixed what I perceived as _real_ bugs, not just adding functionality). Though, to be honest I didn't think about performing sanitizing in that fashion... Of course, if you really want that functionality you can add it ;-) - -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkOdBkACgkQfEfFJ9JhvyhjYgCggEcRquF+BmZSCkVpxt3dY1sT pI4AnjV5em0zVrTxHQtdf2J6ibOZ121d =qd3I -----END PGP SIGNATURE----- From dons at galois.com Sun Nov 2 23:47:50 2008 From: dons at galois.com (Don Stewart) Date: Sun Nov 2 23:42:29 2008 Subject: [Haskell-cafe] Arch Haskell News: Nov 02 2008 Message-ID: <20081103044750.GA21021@scytale.galois.com> News about the Haskell packages for Arch Linux. Highlights, * 672 Haskell packages now supported in Arch Linux, up 33 from two weeks ago. Noteworthy, * haskell-tcache-0.5.3: ?A Transactional data cache with configurable persistence? * haskell-yampa-0.9.2.3: ?Library for programming hybrid systems.? * haskell-network-bytestring-0.1.1.3: ?Fast and memory efficient low-level networking? * haskell-checkers-0.1.1: ?Check properties on standard classes and data structures.? * haskell-coreerlang-0.0.1: ?Facilities for manipulating Core Erlang source code: an abstract syntax, parser and pretty-printer.? Full update list, http://archhaskell.wordpress.com/2008/11/03/arch-haskell-news-nov-02-2008/ -- Don How's your favourite distro doing? If its not up to scratch, talk to someone. From ketil at malde.org Mon Nov 3 02:20:46 2008 From: ketil at malde.org (Ketil Malde) Date: Mon Nov 3 02:15:41 2008 Subject: [Haskell-cafe] Automatic parallelism in Haskell, similar to "make -j4"? In-Reply-To: <1358228143.20081103024440@gmail.com> (Bulat Ziganshin's message of "Mon\, 3 Nov 2008 02\:44\:40 +0300") References: <9c72296b0811021528w596e07b4pbd8ed46cdd7ef6c6@mail.gmail.com> <1358228143.20081103024440@gmail.com> Message-ID: <87od0xxokx.fsf@malde.org> Bulat Ziganshin writes: > Hello T, > > Monday, November 3, 2008, 2:28:08 AM, you wrote: > >> What would it take to implement a -j equivalent for, say, GHC? Or if >> this is not possible, what is wrong with my reasoning? > > problem is that make have rather large pices of work which it can run > parallel. if ghc will try to parallel every machine operation, it will > pend more time maintaining these jobs. 'par' is just the way to tell > GHC "this part of job is large enough" ..and also that this piece of work will actually need to be evaluated. With lazyness, a program can have subexpressions that are bottom as long as they are not evaluated, any kind of speculative execution must take care to handle this properly. -k -- If I haven't seen further, it is by standing in the footprints of giants From bulat.ziganshin at gmail.com Mon Nov 3 02:47:30 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Nov 3 02:50:21 2008 Subject: [Haskell-cafe] Automatic parallelism in Haskell, similar to "make -j4"? In-Reply-To: <9c72296b0811021642s7b65633fq795f0208d3a77746@mail.gmail.com> References: <9c72296b0811021528w596e07b4pbd8ed46cdd7ef6c6@mail.gmail.com> <1358228143.20081103024440@gmail.com> <9c72296b0811021642s7b65633fq795f0208d3a77746@mail.gmail.com> Message-ID: <613694080.20081103104730@gmail.com> Hello T, Monday, November 3, 2008, 3:42:49 AM, you wrote: > On Sun, Nov 2, 2008 at 6:44 PM, Bulat Ziganshin > wrote: >>> What would it take to implement a -j equivalent for, say, GHC? Or if >>> this is not possible, what is wrong with my reasoning? >> >> problem is that make have rather large pices of work which it can run >> parallel. if ghc will try to parallel every machine operation, it will >> pend more time maintaining these jobs. 'par' is just the way to tell >> GHC "this part of job is large enough" > Right, but couldn't the Haskell complier+runtime discover "rather > large pieces of work"? are you ever herd about "halting problem"? it's imposible in general case and i doubt how far it may be done on practice. in general, it looks close to really compute the function (and you still need to know its actual input params!) anyway it's not done and i don't heard about researches in this direction -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Mon Nov 3 02:50:30 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Nov 3 02:50:25 2008 Subject: [Haskell-cafe] Making 'community' server our social network In-Reply-To: References: Message-ID: <1673015235.20081103105030@gmail.com> Hello Maur??cio, Monday, November 3, 2008, 4:43:26 AM, you wrote: > darcs add .emacs > darcs get http://code.haskell.org/MauricioAntunes thank, it's a great ideas! and don't forget that you can use code.haskell.org as online backup of history of your config files -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From barsoap at web.de Mon Nov 3 03:09:15 2008 From: barsoap at web.de (Achim Schneider) Date: Mon Nov 3 03:04:23 2008 Subject: [Haskell-cafe] Re: ANNOUNCE: Graphalyze-0.5 and SourceGraph-0.3 References: <20081103133558.5512b2d9@gmail.com> Message-ID: <20081103090915.11f1d9c5@solaris> Ivan Lazar Miljenovic wrote: > This report contains visualisation of the code for each module, for > the imports (similar to what graphmod [5] does) as well as the entire > code base. > We cna haz screenshotz? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From bulat.ziganshin at gmail.com Mon Nov 3 03:07:26 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Nov 3 03:10:25 2008 Subject: [Haskell-cafe] a minimal Windows program in Haskell? In-Reply-To: <220034.92058.qm@web57402.mail.re1.yahoo.com> References: <220034.92058.qm@web57402.mail.re1.yahoo.com> Message-ID: <854180513.20081103110726@gmail.com> Hello Nun, Monday, November 3, 2008, 6:18:12 AM, you wrote: > How do I make a minimal Windows application in Haskell?? I know you should look at Win32 package sources which includes small example using WinAPI for "hello world" GUI application but note that Win32 binding is far from complete. if i will start to write WinAPI GUI app, i may prefer to do GUI part in C and communicate to Haskell part via FFI ps: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.1-src.tar.bz2 ghc-6.10.1\libraries\Win32\examples -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Mon Nov 3 04:49:10 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Nov 3 04:44:11 2008 Subject: [Haskell-cafe] Making 'community' server our social network In-Reply-To: References: Message-ID: <1225705750.8437.221.camel@localhost> On Sun, 2008-11-02 at 23:43 -0200, Maur??cio wrote: > Then I thought community.haskell.org could offer a default darcs > repositories for all users named after their owners. For instance, > if you want to check my personal files you would do: > > darcs get http://code.haskell.org/MauricioAntunes You can already do this. Just put a darcs repo in your ~/public_html/ dir and access it via http://community.haskell.org/~username/ Duncan From tobias.bexelius at avalanchestudios.se Mon Nov 3 05:31:55 2008 From: tobias.bexelius at avalanchestudios.se (Tobias Bexelius) Date: Mon Nov 3 05:26:53 2008 Subject: [Haskell-cafe] Memory efficiency questions for real-time graphics In-Reply-To: <9c72296b0811021110n3b4b5377hd64217052ce62d3c@mail.gmail.com> References: <9c72296b0810271903s31e9cf65y9818caf189ebd7ef@mail.gmail.com><3d96ac180810281224h69dc0fb7m2a84882bdecafa7c@mail.gmail.com><9c72296b0811011157ke3b6815o7a69653efd8cca92@mail.gmail.com><3d96ac180811011211j2d4bf128q42c9e606bf9cf0d7@mail.gmail.com> <9c72296b0811021110n3b4b5377hd64217052ce62d3c@mail.gmail.com> Message-ID: <698E8783CC407F4EB0DC9E994B6D4540CB1A83@nut.avalanchestudios.se> Before Direct3D 10, its too costly to read back the updated vertex data in every frame, which force you to make this kind of operations on the CPU. With D3D 10 however, you should use the new Stream-Output stage which is used to return updated vertex data directly to a vertex buffer on the GPU. So if you can afford a new graphics card and likes Vista, that's the way to go :) /Tobias -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of T Willingham Sent: den 2 november 2008 20:11 To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Memory efficiency questions for real-time graphics On Sat, Nov 1, 2008 at 2:11 PM, Sebastian Sylvan wrote: > On Sat, Nov 1, 2008 at 6:57 PM, T Willingham > >> >> The per-vertex computation is a quite complex time-dependent function >> applied to the given domain on each update. Yet even if it were >> simple, I would still first implement the formulas in Haskell and >> leave the optimization for later, if at all. > > I'd be very surprised to see a vertex transform that would be faster > to implement on the CPU than the GPU. It appears you misunderstood "complex time-dependent function". This is quite a bit of Haskell code involving a significant amount of octonion algebra. It could, in principle, be put on the GPU, however that should be the very last step after everything else works. > There are various ways of writing out your vertex data too, so if it > doesn't change too often you can still do the transformation on the > GPU, As I previously stated, it changes every frame. Take a highly complicated function and apply it to N vertices. Now increase N until the framerate is affected. That is where I am. It is obvious that any N-sized allocations will cause the framerate to stutter. This is not just theoretical: I *see* it as I increase N while it's running. This is the point of my initial email, the subject of which is memory efficiency. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe From mad.one at gmail.com Mon Nov 3 05:39:56 2008 From: mad.one at gmail.com (Austin Seipp) Date: Mon Nov 3 05:34:54 2008 Subject: [Haskell-cafe] Automatic parallelism in Haskell, similar to "make -j4"? In-Reply-To: <9c72296b0811021528w596e07b4pbd8ed46cdd7ef6c6@mail.gmail.com> References: <9c72296b0811021528w596e07b4pbd8ed46cdd7ef6c6@mail.gmail.com> Message-ID: <1225708131-sup-1240@existential.local> Excerpts from t.r.willingham's message of Sun Nov 02 17:28:08 -0600 2008: > What would it take to implement a -j equivalent for, say, GHC? Or if > this is not possible, what is wrong with my reasoning? > > Thanks, > TW Hi, The main issue has to do with the decisions the compiler needs to make in order to generate adequate code for a general case. The problem is the compiler has to make decisions about the *granularity* of the threading in particular - the generated code for example may waste a lot of time sparking off threads using 'par' or something, for computations that take less time than the thread-creation itself, meaning the overall cost of that thread being spawned was negative. So your code would need the threading to be more coarse-grained. On the other hand, if you have some computation, the compiler may not adequately sprinkle enough par's throughout the program, and therefore we miss opportunities where the parallelism could give us a speed up - in this case, we need more fine-grained threading. So the problem is (in the general case): given an arbitrary input program, how do you adequately decide what should and should not be parallelized in that program? Even then, how do you decide the granularity at which the threads should operate? It's a pretty tough problem, and I don't think we're even close to full-blown automagically-parallelizing compilers (although with things like parallel strategies and DPH we can get close.) But there is work in this area using profiling information to guide these optimizations, see "Feedback directed implicit parallelism" here: http://research.microsoft.com/~tharris/papers/2007-fdip.pdf Austin From duncan.coutts at worc.ox.ac.uk Mon Nov 3 05:59:16 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Nov 3 05:54:17 2008 Subject: [Haskell-cafe] Cairo build fail on OS X Leapord In-Reply-To: <4165d3a70810311155y35763330u16ad26b712ddcdde@mail.gmail.com> References: <4165d3a70810311155y35763330u16ad26b712ddcdde@mail.gmail.com> Message-ID: <1225709956.8437.226.camel@localhost> On Fri, 2008-10-31 at 14:55 -0400, Jefferson Heard wrote: > Installing gtk2hs from MacPorts on a clean mac: > svgcairo/Graphics/Rendering/Cairo/SVG.chs:201:2: > Couldn't match expected type `()' against inferred type `CInt' The latest major release of the cairo C lib changed the API to return an int status code for a C function that previously returned void. c2hs guarantees us some degree of cross-language type safety and caught this api change for us (by turning it into a Haskell type error). I expect the updates to work with the new cairo api are in the gtk2hs darcs version. Duncan From patai_gergely at fastmail.fm Mon Nov 3 07:31:33 2008 From: patai_gergely at fastmail.fm (Patai Gergely) Date: Mon Nov 3 07:26:29 2008 Subject: [Haskell-cafe] Problems with strictness analysis? Message-ID: <1225715493.29387.1282684893@webmail.messagingengine.com> Hi everyone, I was experimenting with simple accumulator functions, and found that an apparently tail recursive function can easily fill the stack. Playing around with ghc and jhc gave consistently unpleasant results. Look at this program: %%%%%%%%%%% -- ghc: no, ghc -O3: yes, jhc: no isum 0 s = s isum n s = isum (n-1) (s+n) -- ghc: no, ghc -O3: no, jhc: yes (because gcc -O3 is clever) rsum 0 = 0 rsum n = n + rsum (n-1) main = case isum 10000000 0 {- rsum 10000000 -} of 0 -> print 0 x -> print x %%%%%%%%%%% I would expect the analysis to find out that the result of the function is needed in every case (since we are matching a pattern to it), yet I need to add a $! to the recursive call of isum to get a truly iterative function. It's interesting how ghc and jhc seem to diverge, one favouring the "iterative" version, the other the "recursive" one (although it only works because gcc figures out that the function can be expressed in an iterative way). Of course this is a real problem when I'm trying to write an actual program, since it means I can be bitten by the laziness bug any time... Is there any solution besides adding strictness annotations? Can I expect the compiler to handle this situation better in the foreseeable future? Gergely -- http://www.fastmail.fm - IMAP accessible web-mail From briqueabraque at yahoo.com Mon Nov 3 07:37:11 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Mon Nov 3 07:32:18 2008 Subject: [Haskell-cafe] Re: Making 'community' server our social network In-Reply-To: <1673015235.20081103105030@gmail.com> References: <1673015235.20081103105030@gmail.com> Message-ID: > Hello Maur??cio, > > Monday, November 3, 2008, 4:43:26 AM, you wrote: > >> darcs add .emacs > >> darcs get http://code.haskell.org/MauricioAntunes > > thank, it's a great ideas! and don't forget that you can use > code.haskell.org as online backup of history of your config files > Nice. Just did that, according to Duncan instructions. I can't share with those who don't know darcs, though, since hidden files (like .emacs or .xmonad directory) do not show up in the web page (code/~mauricio). So my next sugestion is that listing of files starting with dots be allowed, if that doesn't cause problems elsewhere. Best, Maur?cio From xs at xaph.net Mon Nov 3 07:49:41 2008 From: xs at xaph.net (Rafal Kolanski) Date: Mon Nov 3 07:44:41 2008 Subject: [Haskell-cafe] Can't figure out source of race condition when using System.Process In-Reply-To: References: <490DB2E4.3090105@xaph.net> Message-ID: <490EF365.1010208@xaph.net> Bryan O'Sullivan wrote: > What is the "it" that segfaults? The Haskell program shouldn't, at least. The Haskell program. It does so rarely, however, and I'm unable to reproduce it with any consistency, only enough to notice something is wrong with what I've written. Upon closer examination my code also returns an error exit code for subprocesses that should've succeeded (pdflatex, but once in a blue moon also pstoedit) similarly rarely. > That said, your code for reading from child processes is wrong. You > should read all of a child's output strictly (i.e. hGetContents alone > will not do the trick) before you wait for its exit status. Your current > scheme reverses this order, and there is hence no guarantee that it will > read anything from the defunct child process. There's some possibility > that this might be the cause of your segfault, which to me would suggest > the presence of a bug in the runtime system. Well, if there's a bug in the runtime system, I'll try to make sure I can reproduce it before filing a report. Meanwhile, you are absolutely right. How would you propose I properly perform that sort of interaction? It's often useful to use external programs to do things for you by throwing data at them and reading (or ignoring) the result until they die. Is there a Haskell idiom for this? Overall, I find Haskell to be very nice. I just keep getting bitten by laziness, at least until I get used to it. Sincerely, Rafal Kolanski. PS. The file I attached is the only real place where concurrency happens in my code. The rest of the uses are simple ... when rendering a slide using cairo: slideNaive = do ... paintLatex "\\textbf{datatype} ref = Ref int $\\mid$ Null" 50 0 ... which calls: paintLatex text x y = do svg <- liftIO $ updateSVG text paintSVG svg 3 x y updateSVG is defined in SVGLatex.hs which I attached earlier, and the rest: paintSVG :: FilePath -> Double -> Double -> Double -> Render () paintSVG file scale' x y = do save svg <- liftIO $ svgNewFromFile file let (w,h) = svgGetSize svg translate x y scale scale' scale' moveTo 0 0 svgRender svg restore which invokes functions defined in: import Graphics.Rendering.Cairo import Graphics.Rendering.Cairo.SVG From xs at xaph.net Mon Nov 3 07:52:02 2008 From: xs at xaph.net (Rafal Kolanski) Date: Mon Nov 3 07:47:02 2008 Subject: [Haskell-cafe] Can't figure out source of race condition when using System.Process In-Reply-To: <20081102210113.GC7406@darcs.net> References: <490DB2E4.3090105@xaph.net> <20081102201525.GB21990@gmx.de> <20081102210113.GC7406@darcs.net> Message-ID: <490EF3F2.80506@xaph.net> David Roundy wrote: > On Sun, Nov 02, 2008 at 09:15:25PM +0100, Marc Weber wrote: >> On Mon, Nov 03, 2008 at 01:02:12AM +1100, Rafal Kolanski wrote: >>> Rafal Kolanski. >>> [...] >> Why do you use forkIO here? It's not necessary. The process will run in >> background on its own. ? > > It looks to me like this code requires a forkIO, not in the writing to inp, > but rather in the reading of out and err. Otherwise, those buffers may > fill up and your process will hang... It seems to be as you say. Trying for a single-threaded solution to this problem always locked up the program, until I found someone's code snippet online using forkIO and extrapolated from that. Sincerely, Rafal Kolanski. From voigt at tcs.inf.tu-dresden.de Mon Nov 3 08:09:49 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Mon Nov 3 08:04:46 2008 Subject: [Haskell-cafe] Can't figure out source of race condition when using System.Process In-Reply-To: <490EF3F2.80506@xaph.net> References: <490DB2E4.3090105@xaph.net> <20081102201525.GB21990@gmx.de> <20081102210113.GC7406@darcs.net> <490EF3F2.80506@xaph.net> Message-ID: <490EF81D.4050406@tcs.inf.tu-dresden.de> Rafal Kolanski wrote: > ..., until I found someone's code > snippet online ... and extrapolated from that. Oh yes, I love that kind of programming. Hardly possible in other languages than Haskell. :-) -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From jefferson.r.heard at gmail.com Mon Nov 3 09:10:17 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Mon Nov 3 09:05:14 2008 Subject: [Haskell-cafe] Cairo build fail on OS X Leapord In-Reply-To: <1225709956.8437.226.camel@localhost> References: <4165d3a70810311155y35763330u16ad26b712ddcdde@mail.gmail.com> <1225709956.8437.226.camel@localhost> Message-ID: <4165d3a70811030610g6e93c4c6l2fbe132277e7ed1@mail.gmail.com> how can we use those from MacPorts? Is it possible? On Mon, Nov 3, 2008 at 5:59 AM, Duncan Coutts wrote: > On Fri, 2008-10-31 at 14:55 -0400, Jefferson Heard wrote: >> Installing gtk2hs from MacPorts on a clean mac: > >> svgcairo/Graphics/Rendering/Cairo/SVG.chs:201:2: >> Couldn't match expected type `()' against inferred type `CInt' > > The latest major release of the cairo C lib changed the API to return an > int status code for a C function that previously returned void. > > c2hs guarantees us some degree of cross-language type safety and caught > this api change for us (by turning it into a Haskell type error). > > I expect the updates to work with the new cairo api are in the gtk2hs > darcs version. > > Duncan > > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From lemming at henning-thielemann.de Mon Nov 3 09:37:28 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Nov 3 09:32:25 2008 Subject: [Haskell-cafe] Re: Making 'community' server our social network In-Reply-To: References: <1673015235.20081103105030@gmail.com> Message-ID: On Mon, 3 Nov 2008, Mauricio wrote: >> Hello Maur??cio, >> >> Monday, November 3, 2008, 4:43:26 AM, you wrote: >> >>> darcs add .emacs >> >>> darcs get http://code.haskell.org/MauricioAntunes >> >> thank, it's a great ideas! and don't forget that you can use >> code.haskell.org as online backup of history of your config files >> > > Nice. Just did that, according to Duncan instructions. > > I can't share with those who don't know darcs, though, since > hidden files (like .emacs or .xmonad directory) do not show up > in the web page (code/~mauricio). So my next sugestion is > that listing of files starting with dots be allowed, if that > doesn't cause problems elsewhere. You may also create symbol links to the files (ln -s) that you want to be visible. Possibly there is also some way to show them using a .htaccess configuration. From svein.ove at aas.no Mon Nov 3 10:45:12 2008 From: svein.ove at aas.no (Svein Ove Aas) Date: Mon Nov 3 10:40:09 2008 Subject: [Haskell-cafe] Memory efficiency questions for real-time graphics In-Reply-To: <698E8783CC407F4EB0DC9E994B6D4540CB1A83@nut.avalanchestudios.se> References: <9c72296b0810271903s31e9cf65y9818caf189ebd7ef@mail.gmail.com> <3d96ac180810281224h69dc0fb7m2a84882bdecafa7c@mail.gmail.com> <9c72296b0811011157ke3b6815o7a69653efd8cca92@mail.gmail.com> <3d96ac180811011211j2d4bf128q42c9e606bf9cf0d7@mail.gmail.com> <9c72296b0811021110n3b4b5377hd64217052ce62d3c@mail.gmail.com> <698E8783CC407F4EB0DC9E994B6D4540CB1A83@nut.avalanchestudios.se> Message-ID: <221b53ab0811030745q536ee74bm5c5c0c7e6183a3ee@mail.gmail.com> On Mon, Nov 3, 2008 at 11:31 AM, Tobias Bexelius wrote: > Before Direct3D 10, its too costly to read back the updated vertex data > in every frame, which force you to make this kind of operations on the > CPU. > With D3D 10 however, you should use the new Stream-Output stage which is > used to return updated vertex data directly to a vertex buffer on the > GPU. So if you can afford a new graphics card and likes Vista, that's > the way to go :) > Or you could use OpenGL, which has supported that since the first GPUs that did were released. From svein.ove at aas.no Mon Nov 3 10:47:38 2008 From: svein.ove at aas.no (Svein Ove Aas) Date: Mon Nov 3 10:42:34 2008 Subject: [Haskell-cafe] Array bug? In-Reply-To: <490DF724.3090903@btinternet.com> References: <490C513A.3030200@btinternet.com> <20081101141430.GA4203@zombie.inf.tu-dresden.de> <490C6E9E.9060703@btinternet.com> <20081102175958.GA4564@zombie.inf.tu-dresden.de> <490DF724.3090903@btinternet.com> Message-ID: <221b53ab0811030747v572fe2d7la0d5e2af479d7d10@mail.gmail.com> On Sun, Nov 2, 2008 at 7:53 PM, Andrew Coppin wrote: > Bertram Felgenhauer wrote: >> >> It's not going to be fixed by itself - the first comment for the >> bug report basically asks interested parties to submit a proposal >> for changing this. >> > > Well I certainly don't have the skill to fix it. (Presumably all that array > stuff is hard-wired into the compiler.) > Actually, it isn't. The code - the bounds-checking code, at least - is fairly plain haskell in the Array package. You could take a look and, quite possibly, fix it. > In my opinion, what we should have is > > 1. An interface that is guaranteed-safe, no matter how inefficient that is. > > 2. An interface that is guaranteed-efficient, no matter how unsafe that is. > > 3. It should be extremely easy to switch from one to the other. > > You write your code against the safe interface, test it until you're happy > with it, and then switch to the fast interface. > Sounds good to me. > Currently, the "safe" interface actually allows out-of-bounds indicies (in a > way which reveals the underlying implementation), and the "fast" interface > isn't publicly supported. Both of these things should be changed. > Go ahead. :) From lemming at henning-thielemann.de Mon Nov 3 10:55:11 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Nov 3 10:50:08 2008 Subject: [Haskell-cafe] Array bug? In-Reply-To: <221b53ab0811030747v572fe2d7la0d5e2af479d7d10@mail.gmail.com> References: <490C513A.3030200@btinternet.com> <20081101141430.GA4203@zombie.inf.tu-dresden.de> <490C6E9E.9060703@btinternet.com> <20081102175958.GA4564@zombie.inf.tu-dresden.de> <490DF724.3090903@btinternet.com> <221b53ab0811030747v572fe2d7la0d5e2af479d7d10@mail.gmail.com> Message-ID: On Mon, 3 Nov 2008, Svein Ove Aas wrote: > On Sun, Nov 2, 2008 at 7:53 PM, Andrew Coppin > >> In my opinion, what we should have is >> >> 1. An interface that is guaranteed-safe, no matter how inefficient that is. >> >> 2. An interface that is guaranteed-efficient, no matter how unsafe that is. >> >> 3. It should be extremely easy to switch from one to the other. >> >> You write your code against the safe interface, test it until you're happy >> with it, and then switch to the fast interface. >> > Sounds good to me. I think it is a good idea to switch this feature on and off by a compiler switch. It does not alter the correctness of a program. If the program is incorrect, the switch does only affect the way how the program goes wrong. From ketil at malde.org Mon Nov 3 11:04:08 2008 From: ketil at malde.org (Ketil Malde) Date: Mon Nov 3 10:59:03 2008 Subject: [Haskell-cafe] Array bug? In-Reply-To: (Henning Thielemann's message of "Mon\, 03 Nov 2008 16\:55\:11 +0100 \(MET\)") References: <490C513A.3030200@btinternet.com> <20081101141430.GA4203@zombie.inf.tu-dresden.de> <490C6E9E.9060703@btinternet.com> <20081102175958.GA4564@zombie.inf.tu-dresden.de> <490DF724.3090903@btinternet.com> <221b53ab0811030747v572fe2d7la0d5e2af479d7d10@mail.gmail.com> Message-ID: <87myggvls7.fsf@malde.org> Henning Thielemann writes: > I think it is a good idea to switch this feature on and off by a > compiler switch. I agree. Same with Int overflow checking, if it can be done at all. The interesting question is how to name it, the obvious -funsafe-optimization might imply that these optimizations are fun and safe, which is probably misleading :-) -k -- If I haven't seen further, it is by standing in the footprints of giants From duncan.coutts at worc.ox.ac.uk Mon Nov 3 13:06:57 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Nov 3 13:01:57 2008 Subject: [Haskell-cafe] Cairo build fail on OS X Leapord In-Reply-To: <4165d3a70811030610g6e93c4c6l2fbe132277e7ed1@mail.gmail.com> References: <4165d3a70810311155y35763330u16ad26b712ddcdde@mail.gmail.com> <1225709956.8437.226.camel@localhost> <4165d3a70811030610g6e93c4c6l2fbe132277e7ed1@mail.gmail.com> Message-ID: <1225735617.8437.235.camel@localhost> On Mon, 2008-11-03 at 09:10 -0500, Jefferson Heard wrote: > how can we use those from MacPorts? Is it possible? Either use macports to downgrade to an older version of the cairo C lib, or grab the darcs version of gtk2hs and try that. If macports only supports has one version of a lib at once (I seem to recall someone saying that's the case) then you'll have to pick the second option. Duncan > On Mon, Nov 3, 2008 at 5:59 AM, Duncan Coutts > wrote: > > On Fri, 2008-10-31 at 14:55 -0400, Jefferson Heard wrote: > >> Installing gtk2hs from MacPorts on a clean mac: > > > >> svgcairo/Graphics/Rendering/Cairo/SVG.chs:201:2: > >> Couldn't match expected type `()' against inferred type `CInt' > > > > The latest major release of the cairo C lib changed the API to return an > > int status code for a C function that previously returned void. > > > > c2hs guarantees us some degree of cross-language type safety and caught > > this api change for us (by turning it into a Haskell type error). > > > > I expect the updates to work with the new cairo api are in the gtk2hs > > darcs version. From derek.a.elkins at gmail.com Mon Nov 3 13:22:44 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Mon Nov 3 13:17:46 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: <1225715493.29387.1282684893@webmail.messagingengine.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> Message-ID: <1225736564.29512.3.camel@derek-laptop> On Mon, 2008-11-03 at 13:31 +0100, Patai Gergely wrote: > Hi everyone, > > I was experimenting with simple accumulator functions, and found that an > apparently tail recursive function can easily fill the stack. Playing > around with ghc and jhc gave consistently unpleasant results. Look at > this program: > > %%%%%%%%%%% > > -- ghc: no, ghc -O3: yes, jhc: no > isum 0 s = s > isum n s = isum (n-1) (s+n) > > -- ghc: no, ghc -O3: no, jhc: yes (because gcc -O3 is clever) > rsum 0 = 0 > rsum n = n + rsum (n-1) > > main = case isum 10000000 0 {- rsum 10000000 -} of > 0 -> print 0 > x -> print x > > %%%%%%%%%%% > > I would expect the analysis to find out that the result of the function > is needed in every case (since we are matching a pattern to it), yet I > need to add a $! to the recursive call of isum to get a truly iterative > function. It's interesting how ghc and jhc seem to diverge, one > favouring the "iterative" version, the other the "recursive" one > (although it only works because gcc figures out that the function can be > expressed in an iterative way). > > Of course this is a real problem when I'm trying to write an actual > program, since it means I can be bitten by the laziness bug any time... > Is there any solution besides adding strictness annotations? Can I > expect the compiler to handle this situation better in the foreseeable > future? Don't write code that relies on strictness analysis for correctness. From dons at galois.com Mon Nov 3 13:36:40 2008 From: dons at galois.com (Don Stewart) Date: Mon Nov 3 13:31:21 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: <1225715493.29387.1282684893@webmail.messagingengine.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> Message-ID: <20081103183640.GD22845@scytale.galois.com> patai_gergely: > Hi everyone, > > I was experimenting with simple accumulator functions, and found that an > apparently tail recursive function can easily fill the stack. Playing > around with ghc and jhc gave consistently unpleasant results. Look at > this program: > > %%%%%%%%%%% > > -- ghc: no, ghc -O3: yes, jhc: no > isum 0 s = s > isum n s = isum (n-1) (s+n) > > -- ghc: no, ghc -O3: no, jhc: yes (because gcc -O3 is clever) > rsum 0 = 0 > rsum n = n + rsum (n-1) > > main = case isum 10000000 0 {- rsum 10000000 -} of > 0 -> print 0 > x -> print x > > %%%%%%%%%%% > > I would expect the analysis to find out that the result of the function > is needed in every case (since we are matching a pattern to it), yet I > need to add a $! to the recursive call of isum to get a truly iterative > function. It's interesting how ghc and jhc seem to diverge, one > favouring the "iterative" version, the other the "recursive" one > (although it only works because gcc figures out that the function can be > expressed in an iterative way). > > Of course this is a real problem when I'm trying to write an actual > program, since it means I can be bitten by the laziness bug any time... > Is there any solution besides adding strictness annotations? Can I > expect the compiler to handle this situation better in the foreseeable > future? I think its sensible not to rely on an analysis to infer the correct reduction strategy for your code. Make the strictness explict, and your code will be more portable and more robust. Also, write in some type annotations. Particularly for atomic types like Int, these give the strictness analyser yet more information to work with. -- Don From dons at galois.com Mon Nov 3 13:55:22 2008 From: dons at galois.com (Don Stewart) Date: Mon Nov 3 13:50:00 2008 Subject: [Haskell-cafe] Array bug? In-Reply-To: <87myggvls7.fsf@malde.org> References: <490C513A.3030200@btinternet.com> <20081101141430.GA4203@zombie.inf.tu-dresden.de> <490C6E9E.9060703@btinternet.com> <20081102175958.GA4564@zombie.inf.tu-dresden.de> <490DF724.3090903@btinternet.com> <221b53ab0811030747v572fe2d7la0d5e2af479d7d10@mail.gmail.com> <87myggvls7.fsf@malde.org> Message-ID: <20081103185522.GF22845@scytale.galois.com> ketil: > Henning Thielemann writes: > > > I think it is a good idea to switch this feature on and off by a > > compiler switch. > > I agree. Same with Int overflow checking, if it can be done at all. > > The interesting question is how to name it, the obvious > > -funsafe-optimization > > might imply that these optimizations are fun and safe, which is > probably misleading :-) The uvector package as -funsafe, which disables bounds checking on primitive reads/writes. It's a compile time flag to cabal that sets a #define, that then let's GHC optimise away a guard. So there's precedent. -- Don From barsoap at web.de Mon Nov 3 14:05:24 2008 From: barsoap at web.de (Achim Schneider) Date: Mon Nov 3 14:00:32 2008 Subject: [Haskell-cafe] Re: Array bug? References: <490C513A.3030200@btinternet.com> <20081101141430.GA4203@zombie.inf.tu-dresden.de> <490C6E9E.9060703@btinternet.com> <20081102175958.GA4564@zombie.inf.tu-dresden.de> <490DF724.3090903@btinternet.com> <221b53ab0811030747v572fe2d7la0d5e2af479d7d10@mail.gmail.com> <87myggvls7.fsf@malde.org> Message-ID: <20081103200524.21449310@solaris> Ketil Malde wrote: > Henning Thielemann writes: > > > I think it is a good idea to switch this feature on and off by a > > compiler switch. > > I agree. Same with Int overflow checking, if it can be done at all. > > The interesting question is how to name it, the obvious > > -funsafe-optimization > > might imply that these optimizations are fun and safe, which is > probably misleading :-) > -fno-paranoia -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From ketil at malde.org Mon Nov 3 14:21:14 2008 From: ketil at malde.org (Ketil Malde) Date: Mon Nov 3 14:16:12 2008 Subject: [Haskell-cafe] Re: Array bug? In-Reply-To: <20081103200524.21449310@solaris> (Achim Schneider's message of "Mon\, 3 Nov 2008 20\:05\:24 +0100") References: <490C513A.3030200@btinternet.com> <20081101141430.GA4203@zombie.inf.tu-dresden.de> <490C6E9E.9060703@btinternet.com> <20081102175958.GA4564@zombie.inf.tu-dresden.de> <490DF724.3090903@btinternet.com> <221b53ab0811030747v572fe2d7la0d5e2af479d7d10@mail.gmail.com> <87myggvls7.fsf@malde.org> <20081103200524.21449310@solaris> Message-ID: <87ej1svcnp.fsf@malde.org> Achim Schneider writes: >> -funsafe-optimization > -fno-paranoia -fno-rd ? (Okay, I'll stop now :-) -k -- If I haven't seen further, it is by standing in the footprints of giants From jonathanccast at fastmail.fm Mon Nov 3 14:15:00 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Nov 3 14:19:15 2008 Subject: [Haskell-cafe] Re: Array bug? In-Reply-To: <87ej1svcnp.fsf@malde.org> References: <490C513A.3030200@btinternet.com> <20081101141430.GA4203@zombie.inf.tu-dresden.de> <490C6E9E.9060703@btinternet.com> <20081102175958.GA4564@zombie.inf.tu-dresden.de> <490DF724.3090903@btinternet.com> <221b53ab0811030747v572fe2d7la0d5e2af479d7d10@mail.gmail.com> <87myggvls7.fsf@malde.org> <20081103200524.21449310@solaris> <87ej1svcnp.fsf@malde.org> Message-ID: <1225739700.11272.62.camel@jcchost> On Mon, 2008-11-03 at 20:21 +0100, Ketil Malde wrote: > Achim Schneider writes: > > >> -funsafe-optimization > > > -fno-paranoia > > -fno-rd ? -fpermit-program-to-crash jcc From svein.ove at aas.no Mon Nov 3 14:56:17 2008 From: svein.ove at aas.no (Svein Ove Aas) Date: Mon Nov 3 14:51:13 2008 Subject: [Haskell-cafe] Array bug? In-Reply-To: References: <490C513A.3030200@btinternet.com> <20081101141430.GA4203@zombie.inf.tu-dresden.de> <490C6E9E.9060703@btinternet.com> <20081102175958.GA4564@zombie.inf.tu-dresden.de> <490DF724.3090903@btinternet.com> <221b53ab0811030747v572fe2d7la0d5e2af479d7d10@mail.gmail.com> Message-ID: <221b53ab0811031156g74d962c9j6492436b0ca10ed3@mail.gmail.com> On Mon, Nov 3, 2008 at 4:55 PM, Henning Thielemann > > I think it is a good idea to switch this feature on and off by a compiler > switch. It does not alter the correctness of a program. If the program is > incorrect, the switch does only affect the way how the program goes wrong. > I disagree. In a normal program, you may want to mix the two - use the safe functions for untrusted input, the unsafe ones once you have already validated the input. Such a switch, if it existed, should only affect the *unsafe* version of the call - this way, it would be possible to remove all chance of corruption from a program at need. Also, of course, the exceptions should be catchable based on the new ghc 6.10 exception library (on ghc 6.10, anyhow) From frantisek.kocun at gmail.com Mon Nov 3 15:12:55 2008 From: frantisek.kocun at gmail.com (frantisek kocun) Date: Mon Nov 3 15:07:51 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: <20081103183640.GD22845@scytale.galois.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> Message-ID: yet I need to add a $! to the recursive call of isum to get a truly iterative ??? Wait a minute Patai. How would you do that? I'm only beginner I thought I can only add strict "!" to data parameters. But to make isum function strict would be helpful. Thanks On Mon, Nov 3, 2008 at 7:36 PM, Don Stewart wrote: > patai_gergely: > > Hi everyone, > > > > I was experimenting with simple accumulator functions, and found that an > > apparently tail recursive function can easily fill the stack. Playing > > around with ghc and jhc gave consistently unpleasant results. Look at > > this program: > > > > %%%%%%%%%%% > > > > -- ghc: no, ghc -O3: yes, jhc: no > > isum 0 s = s > > isum n s = isum (n-1) (s+n) > > > > -- ghc: no, ghc -O3: no, jhc: yes (because gcc -O3 is clever) > > rsum 0 = 0 > > rsum n = n + rsum (n-1) > > > > main = case isum 10000000 0 {- rsum 10000000 -} of > > 0 -> print 0 > > x -> print x > > > > %%%%%%%%%%% > > > > I would expect the analysis to find out that the result of the function > > is needed in every case (since we are matching a pattern to it), yet I > > need to add a $! to the recursive call of isum to get a truly iterative > > function. It's interesting how ghc and jhc seem to diverge, one > > favouring the "iterative" version, the other the "recursive" one > > (although it only works because gcc figures out that the function can be > > expressed in an iterative way). > > > > Of course this is a real problem when I'm trying to write an actual > > program, since it means I can be bitten by the laziness bug any time... > > Is there any solution besides adding strictness annotations? Can I > > expect the compiler to handle this situation better in the foreseeable > > future? > > I think its sensible not to rely on an analysis to infer the correct > reduction strategy for your code. Make the strictness explict, and your > code will be more portable and more robust. > > Also, write in some type annotations. Particularly for atomic types like > Int, these give the strictness analyser yet more information to work > with. > > -- Don > _______________________________________________ > 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/20081103/543e2f34/attachment-0001.htm From nunofaurbiz at yahoo.com Mon Nov 3 15:53:08 2008 From: nunofaurbiz at yahoo.com (Nun Aurbiz) Date: Mon Nov 3 15:48:05 2008 Subject: [Haskell-cafe] a minimal Windows program in Haskell? In-Reply-To: <854180513.20081103110726@gmail.com> Message-ID: <260276.61925.qm@web57403.mail.re1.yahoo.com> Bulat Ziganshin wrote: ps: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.1-src.tar.bz2 ghc-6.10.1\libraries\Win32\examples Thanks for this. I noticed some errors in the sample that might help others: 1) you need to replace "win32" with "Win32" in the given command line instruction 2) the Win32 package in this link gives a type error during the "setup build" phase (expecting exception and given ioerror?) but you can compile the example against the Win32 package in ghc 6.8.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081103/bc02e920/attachment.htm From agocorona at gmail.com Mon Nov 3 16:01:59 2008 From: agocorona at gmail.com (Alberto G. Corona ) Date: Mon Nov 3 15:56:57 2008 Subject: Fwd: [Haskell-cafe] Re: [Haskell] ANNOUNCE: RefSerialize-0.2.1 In-Reply-To: References: <992447070.20081102174848@gmail.com> Message-ID: I forgot to cc to haskell-cafe: ---------- Forwarded message ---------- From: Alberto G. Corona Date: 2008/11/2 Subject: Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: RefSerialize-0.2.1 To: Bulat Ziganshin * SerTH is a binary serialization library for Haskell. It supports serializing cyclic datatypes in a fast binary format. SerTH uses template haskell for deriving the serializing interface for new datatypes. *Too bad...I did not know it. Not even many people in the #haskell channel, where i discussed about how badly a functionality such that is needed. It restores the references when data is deserialized?. My package is text oriented and the serialization is readable and eval-uable, so can be used also for debugging purposes. I use System.Mem.StableName. for it. 2008/11/2 Bulat Ziganshin Hello Alberto, > > Sunday, November 2, 2008, 5:02:10 PM, you wrote: > > Read, Show and Data.Binary do not check for repeated references to > > the same data address. > > afair, SerTH does it, using GHC's internal address compare function > > what way to check for copies you use? > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081103/a5427e8b/attachment.htm From agocorona at gmail.com Mon Nov 3 16:03:26 2008 From: agocorona at gmail.com (Alberto G. Corona ) Date: Mon Nov 3 15:58:22 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: RefSerialize-0.2.1 In-Reply-To: References: Message-ID: actualized to 0.2.3 due to some errors in the cabal description. Sorry, some needed module was not exported. 2008/11/2 Alberto G. Corona > I uploadad RefSerialize > to Hackage . > > Read, Show and Data.Binary do not check for repeated references to the same > data address. As a result, the data is serialized multiple times when > serialized. This is a waste of space in the filesystem and also a waste of > serialization time. but the worst consequence is that, when the serialized > data is read, it allocates multiple copies in memory for the same object > referenced multiple times. Because multiple referenced data is very typical > in a pure language such is Haskell, this means that the resulting data loose > the beatiful economy of space and processing time that referential > transparency permits. > > This package allows the serialization and deserialization of large data > structures without duplication of data, with > the result of optimized performance and memory usage. It is also useful for > debugging purposes. > > There are automatic derived instances for instances of Read/Show, lists and > strings. the deserializer contains a almos complete set of Parsec.Token > parsers for deserialization. > > Every instance of Show/Read is also a instance of Data.RefSerialize > > The serialized string has the form "expr( var1, ...varn) where > var1=value1,..valn=valueN " so that the > string can ve EVALuated. > > See demo.hs and tutorial. I presumably will add a entry in > haskell-web.blogspot.com > > To develop: -derived instances for Data.Binary > -serialization to/from ByteStings > > I wrote this module because I needed to serialize lists of verisions of the > same data with slight modifications between each version. > > > This is a short tutorial (in tutorial.txt) > > > > runW applies showp, the serialization parser of the instance Int for the > RefSerialize class > > Data.RefSerialize>let x= 5 :: Int > Data.RefSerialize>runW $ showp x > "5" > > every instance of Read and Show is an instance of RefSerialize. > > rshowp is derived from showp, it labels the serialized data with a variable > name > > Data.RefSerialize>runW $ rshowp x > " v8 where {v8= 5; }" > > Data.RefSerialize>runW $ rshowp [2::Int,3::Int] > " v6 where {v6= [ v9, v10]; v9= 2; v10= 3; }" > > while showp does a normal show serialization > > Data.RefSerialize>runW $ showp [x,x] > "[5, 5]" > > rshowp variables are serialized memory references: no piece of data that > point to the same addrees is serialized but one time > > Data.RefSerialize>runW $ rshowp [x,x] > " v9 where {v6= 5; v9= [ v6, v6]; }" > > This happens recursively > > Data.RefSerialize>let xs= [x,x] in str = runW $ rshowp [xs,xs] > Data.RefSerialize>str > " v8 where {v8= [ v10, v10]; v9= 5; v10= [ v9, v9]; }" > > the rshowp serialized data is read with rreadp. The showp serialized data > is read by readp > > Data.RefSerialize>let xss= runR rreadp str :: [[Int]] > Data.RefSerialize>print xss > [[5,5],[5,5]] > > this is the deserialized data > > the deserialized data keep the references!! pointers are restored! That is > the whole point! > > Data.RefSerialize>varName xss !! 0 == varName xss !! 1 > True > > > rShow= runW rshowp > rRead= runR rreadp > > Data.RefSerialize>rShow x > " v11 where {v11= 5; }" > > > In the definition of a referencing parser non referencing parsers can be > used and viceversa. Use a referencing parser > when the piece of data is being referenced many times inside the serialized > data. > > by default the referencing parser is constructed by: > > rshowp= insertVar showp > rreadp= readVar readp > but this can be redefined. See for example the instance of [] in > RefSerialize.hs > > This is an example of a showp parser for a simple data structure. > > data S= S Int Int deriving ( Show, Eq) > > instance Serialize S where > showp (S x y)= do > xs <- rshowp x -- rshowp parsers can be inside showp > parser > ys <- rshowp y > return $ "S "++xs++" "++ys > > > > readp = do > symbol "S" -- I included a (almost) complete Parsec > for deserialization > x <- rreadp > y <- rreadp > return $ S x y > > there is a mix between referencing and no referencing parser here: > > Data.RefSerialize>putStrLn $ runW $ showp $ S x x > S v23 v23 where {v23= 5; } > > > (I corrected some errors in this file here) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081103/1fe890fa/attachment.htm From lemming at henning-thielemann.de Mon Nov 3 16:05:34 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Nov 3 16:00:30 2008 Subject: [Haskell-cafe] Array bug? In-Reply-To: <221b53ab0811031156g74d962c9j6492436b0ca10ed3@mail.gmail.com> References: <490C513A.3030200@btinternet.com> <20081101141430.GA4203@zombie.inf.tu-dresden.de> <490C6E9E.9060703@btinternet.com> <20081102175958.GA4564@zombie.inf.tu-dresden.de> <490DF724.3090903@btinternet.com> <221b53ab0811030747v572fe2d7la0d5e2af479d7d10@mail.gmail.com> <221b53ab0811031156g74d962c9j6492436b0ca10ed3@mail.gmail.com> Message-ID: On Mon, 3 Nov 2008, Svein Ove Aas wrote: > On Mon, Nov 3, 2008 at 4:55 PM, Henning Thielemann >> >> I think it is a good idea to switch this feature on and off by a compiler >> switch. It does not alter the correctness of a program. If the program is >> incorrect, the switch does only affect the way how the program goes wrong. >> > > I disagree. > In a normal program, you may want to mix the two - use the safe > functions for untrusted input, the unsafe ones once you have already > validated the input. > > Such a switch, if it existed, should only affect the *unsafe* version > of the call - this way, it would be possible to remove all chance of > corruption from a program at need. > > Also, of course, the exceptions should be catchable based on the new > ghc 6.10 exception library (on ghc 6.10, anyhow) I think you mix up errors and exceptions: http://www.haskell.org/haskellwiki/Exception http://www.haskell.org/haskellwiki/Error If you read untrusted data and encounter an index out of range, then you must throw an exception (or return an "exception code"). The internal array bound checking must be active though, since your code that checks the untrusted data may be buggy. The internal array bound checking is entirely intended for revealing buggy code, not for validating untrusted data. That is, for debugging you turn the bound checking on and if you are sure it is exhaustively tested, then you can turn it off for maximum efficiency. You may want to give http://hackage.haskell.org/cgi-bin/hackage-scripts/package/explicit-exception a try. From agocorona at gmail.com Mon Nov 3 16:16:14 2008 From: agocorona at gmail.com (Alberto G. Corona ) Date: Mon Nov 3 16:11:10 2008 Subject: [Haskell-cafe] huge single file syncronization Message-ID: I need to backup my ubuntu-VMWare image frequently (5 GBits) . I need to know if exist such a utility (in haskell or not) for single file syncronization. I don?t want to reinvent te weel, but I think that it is a few lines of Haskell using the Diff package or something similar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081103/28cf20db/attachment.htm From duncan.coutts at worc.ox.ac.uk Mon Nov 3 16:30:10 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Nov 3 16:25:28 2008 Subject: [Haskell-cafe] huge single file syncronization In-Reply-To: References: Message-ID: <1225747810.8437.240.camel@localhost> On Mon, 2008-11-03 at 22:16 +0100, Alberto G. Corona wrote: > I need to backup my ubuntu-VMWare image frequently (5 GBits) . I > need to know if exist such a utility (in haskell or not) for single > file syncronization. > > > I don?t want to reinvent te weel, but I think that it is a few lines > of Haskell using the Diff package or something similar. You could try rsync and make sure to put it into it's binary diff mode (for local files it sometimes defaults to simple copy). Duncan From dons at galois.com Mon Nov 3 16:35:24 2008 From: dons at galois.com (Don Stewart) Date: Mon Nov 3 16:30:07 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> Message-ID: <20081103213524.GY22845@scytale.galois.com> frantisek.kocun: > yet I need to add a $! to the recursive call of isum to get a truly > iterative ??? > > Wait a minute Patai. How would you do that? I'm only beginner I thought I > can only add strict "!" to data parameters. But to make isum function > strict would be helpful. > Consider this program, isum 0 s = s isum n s = isum (n-1) (s+n) main = case isum 10000000 0 {- rsum 10000000 -} of 0 -> print 0 x -> print x Now, isum is *not* strict in 's', so without some additional hints or analysis, this won't be evaluated until the result of isum is required. It will build up a long change of (s + n) on the stack. -O0 $ time ./A Stack space overflow: current size 8388608 bytes. Of course, we make this strict in a number of ways: * Turning on optimisations: -O2 $ time ./A 50000005000000 ./A 0.31s user 0.00s system 99% cpu 0.312 total * Use an explict bang pattern on the 's' variable: {-# LANGUAGE BangPatterns #-} isum 0 s = s isum n !s = isum (n-1) (s+n) -O0 $ time ./A 50000005000000 ./A 0.69s user 0.00s system 95% cpu 0.721 total Note that by being explict about the strictness in 's' this program produces the desired result even with all optimisations disabled. We can then turn on other optimisations: -O2 -fvia-C -optc-O2 $ time ./A 50000005000000 ./A 0.31s user 0.00s system 101% cpu 0.313 total And it just gets faster. Now, we can also add an explicit type signature to constrain to a machine Int: -O2 -fvia-C -optc-O2 $ time ./A 50000005000000 ./A 0.03s user 0.00s system 100% cpu 0.033 total Meaing the final version is: isum :: Int -> Int -> Int isum 0 s = s isum n !s = isum (n-1) (s+n) So: if you rely on tail recursion on a particular variable, make sure it is enforced as strict. That's the simplest, most robust way to ensure the reduction strategy you want is used. -- Don From greenrd at greenrd.org Mon Nov 3 16:49:32 2008 From: greenrd at greenrd.org (Robin Green) Date: Mon Nov 3 16:44:37 2008 Subject: [Haskell-cafe] huge single file syncronization In-Reply-To: References: Message-ID: <20081103214932.1e279a06@greenrd.org> On Mon, 3 Nov 2008 22:16:14 +0100 "Alberto G. Corona " wrote: > I need to backup my ubuntu-VMWare image frequently (5 GBits) . I > need to know if exist such a utility (in haskell or not) for single > file syncronization. Why don't you just run rsync inside the virtual machine? That way, you will avoid unnecessarily synchronising old data from deleted files, or files that have been truncated. A Haskell library and/or GUI for rsync (to allow you to configure all the possible command-line options) would be a nice thing to have. -- Robin From lrpalmer at gmail.com Mon Nov 3 16:49:54 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Nov 3 16:44:50 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: <20081103213524.GY22845@scytale.galois.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> Message-ID: <7ca3f0160811031349v51b28ef4tbb83d8bb04aac7f5@mail.gmail.com> On Mon, Nov 3, 2008 at 2:35 PM, Don Stewart wrote: > Consider this program, > > isum 0 s = s > isum n s = isum (n-1) (s+n) > > main = case isum 10000000 0 {- rsum 10000000 -} of > 0 -> print 0 > x -> print x > > Now, isum is *not* strict in 's', [...] > > Of course, we make this strict in a number of ways: > > * Turning on optimisations: I am confused about your usage of "strict". Optimizations are not supposed to change semantics, so I don't know how it is possible to make a function strict by turning on optimizations. This function was always strict in s, given a strict numeral type. By induction on n: isum 0 _|_ = _|_ isum (n+1) _|_ = isum n (s+_|_) = isum n _|_ = _|_ For negative n, it either wraps around to positive in which case the above analysis applies, or it does not halt, which is strict (in the same way "const _|_" is strict). Luke From lrpalmer at gmail.com Mon Nov 3 16:53:05 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Nov 3 16:48:00 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: <7ca3f0160811031349v51b28ef4tbb83d8bb04aac7f5@mail.gmail.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <7ca3f0160811031349v51b28ef4tbb83d8bb04aac7f5@mail.gmail.com> Message-ID: <7ca3f0160811031353v2b10e5d1xafc09636c03ae534@mail.gmail.com> On Mon, Nov 3, 2008 at 2:49 PM, Luke Palmer wrote: > I am confused about your usage of "strict". Optimizations are not > supposed to change semantics, so I don't know how it is possible to > make a function strict by turning on optimizations. This function was > always strict in s, given a strict numeral type. By induction on n: > > isum 0 _|_ = _|_ > isum (n+1) _|_ = isum n (s+_|_) = isum n _|_ = _|_ Modulo math bugs :-) isum (n+1) _|_ = isum n (_|_+n) = isum n _|_ = _|_ Luke From dons at galois.com Mon Nov 3 16:54:24 2008 From: dons at galois.com (Don Stewart) Date: Mon Nov 3 16:49:29 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: <7ca3f0160811031349v51b28ef4tbb83d8bb04aac7f5@mail.gmail.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <7ca3f0160811031349v51b28ef4tbb83d8bb04aac7f5@mail.gmail.com> Message-ID: <20081103215424.GZ22845@scytale.galois.com> lrpalmer: > On Mon, Nov 3, 2008 at 2:35 PM, Don Stewart wrote: > > Consider this program, > > > > isum 0 s = s > > isum n s = isum (n-1) (s+n) > > > > main = case isum 10000000 0 {- rsum 10000000 -} of > > 0 -> print 0 > > x -> print x > > > > Now, isum is *not* strict in 's', [...] > > > > Of course, we make this strict in a number of ways: > > > > * Turning on optimisations: > > I am confused about your usage of "strict". Optimizations are not > supposed to change semantics, so I don't know how it is possible to > make a function strict by turning on optimizations. This function was > always strict in s, given a strict numeral type. By induction on n: > > isum 0 _|_ = _|_ > isum (n+1) _|_ = isum n (s+_|_) = isum n _|_ = _|_ > > For negative n, it either wraps around to positive in which case the > above analysis applies, or it does not halt, which is strict (in the > same way "const _|_" is strict). "Optimisations" enable strictness analysis. -- Don From lrpalmer at gmail.com Mon Nov 3 17:02:15 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Nov 3 16:57:10 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: <20081103215424.GZ22845@scytale.galois.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <7ca3f0160811031349v51b28ef4tbb83d8bb04aac7f5@mail.gmail.com> <20081103215424.GZ22845@scytale.galois.com> Message-ID: <7ca3f0160811031402t780e1ad0sedf8201f122337bd@mail.gmail.com> On Mon, Nov 3, 2008 at 2:54 PM, Don Stewart wrote: > lrpalmer: >> On Mon, Nov 3, 2008 at 2:35 PM, Don Stewart wrote: >> > Consider this program, >> > >> > isum 0 s = s >> > isum n s = isum (n-1) (s+n) >> > >> > main = case isum 10000000 0 {- rsum 10000000 -} of >> > 0 -> print 0 >> > x -> print x >> > >> > Now, isum is *not* strict in 's', [...] >> > >> > Of course, we make this strict in a number of ways: >> > >> > * Turning on optimisations: >> >> I am confused about your usage of "strict". Optimizations are not >> supposed to change semantics, so I don't know how it is possible to >> make a function strict by turning on optimizations. This function was >> always strict in s, given a strict numeral type. By induction on n: >> >> isum 0 _|_ = _|_ >> isum (n+1) _|_ = isum n (s+_|_) = isum n _|_ = _|_ >> >> For negative n, it either wraps around to positive in which case the >> above analysis applies, or it does not halt, which is strict (in the >> same way "const _|_" is strict). > > "Optimisations" enable strictness analysis. I was actually being an annoying purist. "f is strict" means "f _|_ = _|_", so strictness is a semantic idea, not an operational one. Optimizations can change operation, but must preserve semantics. But I'm not just picking a fight. I'm trying to promote equational reasoning over operational reasoning in the community, since I believe that is Haskell's primary strength. Luke From Ivan.Miljenovic at gmail.com Mon Nov 3 17:05:57 2008 From: Ivan.Miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon Nov 3 17:01:02 2008 Subject: [Haskell-cafe] Re: ANNOUNCE: Graphalyze-0.5 and SourceGraph-0.3 References: <20081103133558.5512b2d9@gmail.com> <20081103090915.11f1d9c5@solaris> Message-ID: Achim Schneider web.de> writes: > > This report contains visualisation of the code for each module, for > > the imports (similar to what graphmod [5] does) as well as the entire > > code base. > > > We cna haz screenshotz? > Well, it's a console app that produces an HTML file, so there's not much to screenshot. If you go to my blog (http://ivanmiljenovic.wordpress.com/), I've uploaded my thesis there, and the appendices include the analyses of Graphalyze and SourceGraph (though since I had to print them to pdf, and then shrink each page to get it to fit it's a bit hard to read). From lemming at henning-thielemann.de Mon Nov 3 17:39:00 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Nov 3 17:33:56 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: <7ca3f0160811031402t780e1ad0sedf8201f122337bd@mail.gmail.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <7ca3f0160811031349v51b28ef4tbb83d8bb04aac7f5@mail.gmail.com> <20081103215424.GZ22845@scytale.galois.com> <7ca3f0160811031402t780e1ad0sedf8201f122337bd@mail.gmail.com> Message-ID: On Mon, 3 Nov 2008, Luke Palmer wrote: > On Mon, Nov 3, 2008 at 2:54 PM, Don Stewart wrote: >> >> "Optimisations" enable strictness analysis. > > I was actually being an annoying purist. "f is strict" means "f _|_ = > _|_", so strictness is a semantic idea, not an operational one. > Optimizations can change operation, but must preserve semantics. > > But I'm not just picking a fight. I'm trying to promote equational > reasoning over operational reasoning in the community, since I believe > that is Haskell's primary strength. Maybe I missed the point, but the optimization seems correct to me. Without optimization and its (strictness) analysis the program would still output the correct answer - given that the stack is sufficiently large. Optimization simply makes this program run using much less space. Right? From dave at zednenem.com Mon Nov 3 17:45:19 2008 From: dave at zednenem.com (David Menendez) Date: Mon Nov 3 17:40:40 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <7ca3f0160811031349v51b28ef4tbb83d8bb04aac7f5@mail.gmail.com> <20081103215424.GZ22845@scytale.galois.com> <7ca3f0160811031402t780e1ad0sedf8201f122337bd@mail.gmail.com> Message-ID: <49a77b7a0811031445s3d5558d9k5e219d7dfe1fb55d@mail.gmail.com> On Mon, Nov 3, 2008 at 5:39 PM, Henning Thielemann wrote: > > On Mon, 3 Nov 2008, Luke Palmer wrote: > >> On Mon, Nov 3, 2008 at 2:54 PM, Don Stewart wrote: >>> >>> "Optimisations" enable strictness analysis. >> >> I was actually being an annoying purist. "f is strict" means "f _|_ = >> _|_", so strictness is a semantic idea, not an operational one. >> Optimizations can change operation, but must preserve semantics. >> >> But I'm not just picking a fight. I'm trying to promote equational >> reasoning over operational reasoning in the community, since I believe >> that is Haskell's primary strength. > > Maybe I missed the point, but the optimization seems correct to me. Without > optimization and its (strictness) analysis the program would still output > the correct answer - given that the stack is sufficiently large. > Optimization simply makes this program run using much less space. Right? I think Luke was commenting on the terminology, not the optimization. We have a tendency to say "lazy" when we mean "non-strict" and "strict" when we mean "eager". -- Dave Menendez From noteed at gmail.com Mon Nov 3 17:58:30 2008 From: noteed at gmail.com (minh thu) Date: Mon Nov 3 17:53:25 2008 Subject: [Haskell-cafe] Typeable and Dynamic Message-ID: <40a414c20811031458w45b0baedybea380e146263ea2@mail.gmail.com> Hi, Given a TypeRep and a Dynamic value with type corresponding to the TypeRep, I'd like to be able to use fromDyn *without* specifying a type (given as an additional 'default' argument) (since it is somewhat known from the TypeRep). That is, I'd like an undefinedOf that can be used in extract :: Typeable a => TypeRep -> Dynamic -> a extract typerep dyn = fromDyn (undefinedOf typerep) dyn For instance, if TypeRep is Int, extract Int dyn = fromDyn (undefined::Int) dyn Is it possible to write "extract" ? Thanks, Thu From haskell at brecknell.org Mon Nov 3 18:35:34 2008 From: haskell at brecknell.org (Matthew Brecknell) Date: Mon Nov 3 18:30:30 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <7ca3f0160811031349v51b28ef4tbb83d8bb04aac7f5@mail.gmail.com> <20081103215424.GZ22845@scytale.galois.com> <7ca3f0160811031402t780e1ad0sedf8201f122337bd@mail.gmail.com> Message-ID: <1225755334.32108.1282807079@webmail.messagingengine.com> Don Stewart: > "Optimisations" enable strictness analysis. Luke Palmer: > I was actually being an annoying purist. "f is strict" means "f _|_ = > _|_", so strictness is a semantic idea, not an operational one. > Optimizations can change operation, but must preserve semantics. Henning Thielemann: > Maybe I missed the point, but the optimization seems correct to me. > [...] I guess the obvious clarification to make here is that strictness analysis doesn't make non-strict functions strict. It is about determining which functions are already strict. The *optimisation* is to transform call-by-need into call-by-value (or something like that). But that's an *operational* matter, as Luke points out. To preserve *semantics*, that transformation can only be allowed for functions which are already strict. Hence the need for strictness analysis as part of optimisation. So everybody is right. :-) From wren at freegeek.org Mon Nov 3 19:37:19 2008 From: wren at freegeek.org (wren ng thornton) Date: Mon Nov 3 19:32:15 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: <1225715493.29387.1282684893@webmail.messagingengine.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> Message-ID: <490F993F.8080109@freegeek.org> Patai Gergely wrote: > Hi everyone, > > I was experimenting with simple accumulator functions, and found that an > apparently tail recursive function can easily fill the stack. Playing > around with ghc and jhc gave consistently unpleasant results. Look at > this program: > > %%%%%%%%%%% > > -- ghc: no, ghc -O3: yes, jhc: no > isum 0 s = s > isum n s = isum (n-1) (s+n) This is tail recursive, and will be optimized to an iterative loop; however, the result of this function is a thunk ((...(s+n)+n')...+1) which can be potentially quite large. Pulling on this thunk is what causes the overflow, since (+) is strict in both arguments and can't return partial answers[1]. This function ---or variants like summing a list--- seems to be the canonical pitfall for people trying to use tail recursion to reason about laziness. In terms of having a compiler 'smart enough', it's not clear that functions of this sort ought to be inferred strict simply because the accumulator is ultimately returned to the caller. Consider for example: > f 0 xs = xs > f n xs = f (n-1) (replicate n n ++ xs) Since (++) can indeed return partial answers, it's fine for the accumulator to be lazy. Indeed, making it strict harms performance significantly. Another example is when the accumulator is a function, as is common in using tail recursion and CPS together. The only way, really, to infer that the accumulator should be strict is if we know 'enough' about the function used to construct the accumulator in order to infer that amortizing the reduction at every iteration is equivalent to or better than deferring it. I'm not sure that this can be done in general without (an expanded type system and) user annotations. Personally I think strictness annotations are a lot clearer than having the type system express all strictness relations or distinguishing data and codata. Laziness is not the enemy, it merely illuminates the question of amortizing costs which eager languages obscure. [1] Assuming you're not using Peano integers or some other lazy encoding in lieu of the built-in Num types. -- Live well, ~wren From aslatter at gmail.com Mon Nov 3 19:58:39 2008 From: aslatter at gmail.com (Antoine Latter) Date: Mon Nov 3 19:53:34 2008 Subject: [Haskell-cafe] Typeable and Dynamic In-Reply-To: <40a414c20811031458w45b0baedybea380e146263ea2@mail.gmail.com> References: <40a414c20811031458w45b0baedybea380e146263ea2@mail.gmail.com> Message-ID: <694519c50811031658q2198c6bk1b9d3695786c54a8@mail.gmail.com> On Mon, Nov 3, 2008 at 4:58 PM, minh thu wrote: > Hi, > > Given a TypeRep and a Dynamic value with type corresponding to the > TypeRep, I'd like to be able to use fromDyn *without* specifying a type > (given as an additional 'default' argument) (since it is somewhat known > from the TypeRep). > > That is, I'd like an undefinedOf that can be used in > > extract :: Typeable a => TypeRep -> Dynamic -> a > extract typerep dyn = fromDyn (undefinedOf typerep) dyn > > For instance, if TypeRep is Int, > extract Int dyn = fromDyn (undefined::Int) dyn > > Is it possible to write "extract" ? > Yep! It's already written: fromDynamic :: Typable a => Dynamic -> Maybe a It returns Nothing if the Dynamic value was of the wrong type. See: http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Dynamic.html#v:fromDynamic -Antoine From nicolas.frisby at gmail.com Mon Nov 3 20:02:55 2008 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Mon Nov 3 19:57:51 2008 Subject: [Haskell-cafe] template haskell overly conservative during splicing? Message-ID: <5ce89fb50811031702x66936740v6eeb6d49b4cc29a7@mail.gmail.com> When using template haskell (via Derive) to generate this (exact) instance: instance Foldable ((->) Int) => Foldable Data.Derivable.InterpreterLib.Test.List where foldMap f (Cons x0 x1) = (const mempty Cons `mappend` foldMap f x0) `mappend` foldMap f x1 foldMap f (Nil) = const mempty Nil I realize the context is insatisfiable. My issue, is that I can't even reach that "challenge". I get this error instead: Malformed type AppT ArrowT (ConT GHC.Base.Int) When splicing generated code into the program I couldn't find an existing ticket or discussion for this issue relying on the phrase "malformed type". I couldn't even find the source that generates that string in haskell-src, template-haskell, or ghc-6.8.2. Can anybody help? Thanks for your time. From oleg at okmij.org Tue Nov 4 00:16:02 2008 From: oleg at okmij.org (oleg@okmij.org) Date: Tue Nov 4 00:11:05 2008 Subject: [Haskell-cafe] Typeable and Dynamic Message-ID: <20081104051602.8F2FFAE54@Adric.metnet.fnmoc.navy.mil> minh thu asked a tricky question, about writing > extract :: Typeable a => TypeRep -> Dynamic -> a The question here is what determines the type 'a'. One answer is that 'a' is determined from the context, e.g., (extract tr dyn) + 1.0 fixes 'a' to be an Int. In that case, extract is equivalent to `read' (indeed, String is a primitive sort of Dynamic). We do not need any argument TypeRep though as we obtain 'a' from the context. fromDynamic is sufficient there. One can also construe the question to be asking about writing an `inverse' of typeOf. Whereas, typeOf :: Typeable a => a -> TypeRep can give the TypeRep for any (Typeable) type, undefinedOf :: Typeable a => TypeRep -> a could give (an undefined) value for a given TypeRep. Now, the _type_ 'a' is determined by the _value_ of TypeRep: seemingly we need dependent types. To write function of exactly that signature, we need Template Haskell. Oftentimes, we can get away with a weaker function: > data Dyn = forall a. Typeable a => Dyn a > reflect :: TypeRep -> Dyn to be used to implement dynApply, dynFst, dynSnd, dynHead and other operations on Dynamics. Perhaps the following message may help then http://www.haskell.org/pipermail/haskell-cafe/2007-December/036820.html From barsoap at web.de Tue Nov 4 02:26:45 2008 From: barsoap at web.de (Achim Schneider) Date: Tue Nov 4 02:21:55 2008 Subject: [Haskell-cafe] Re: ANNOUNCE: Graphalyze-0.5 and SourceGraph-0.3 References: <20081103133558.5512b2d9@gmail.com> <20081103090915.11f1d9c5@solaris> Message-ID: <20081104082645.159da37a@solaris> Ivan Lazar Miljenovic wrote: > Achim Schneider web.de> writes: > > > > This report contains visualisation of the code for each module, > > > for the imports (similar to what graphmod [5] does) as well as > > > the entire code base. > > > > > We cna haz screenshotz? > > > > Well, it's a console app that produces an HTML file, so there's not > much to screenshot. If you go to my blog > (http://ivanmiljenovic.wordpress.com/), I've uploaded my thesis > there, and the appendices include the analyses of Graphalyze and > SourceGraph (though since I had to print them to pdf, and then shrink > each page to get it to fit it's a bit hard to read). > That's about what I meant with a screenshot. Linking a copy of the html generated for e.g. the Prelude would greatly help people who are just browsing Hackage and are trying to figure out what your package is all about. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From barsoap at web.de Tue Nov 4 02:43:28 2008 From: barsoap at web.de (Achim Schneider) Date: Tue Nov 4 02:38:37 2008 Subject: [Haskell-cafe] Re: template haskell overly conservative during splicing? References: <5ce89fb50811031702x66936740v6eeb6d49b4cc29a7@mail.gmail.com> Message-ID: <20081104084328.11049a60@solaris> "Nicolas Frisby" wrote: > When using template haskell (via Derive) to generate this (exact) > instance: > > instance Foldable ((->) Int) => Foldable > Data.Derivable.InterpreterLib.Test.List > where foldMap f (Cons x0 x1) = (const mempty Cons `mappend` > foldMap f x0) `mappend` foldMap f x1 > foldMap f (Nil) = const mempty Nil > > I realize the context is insatisfiable. My issue, is that I can't even > reach that "challenge". I get this error instead: > > Malformed type AppT ArrowT (ConT GHC.Base.Int) > When splicing generated code into the program > > I couldn't find an existing ticket or discussion for this issue > relying on the phrase "malformed type". I couldn't even find the > source that generates that string in haskell-src, template-haskell, or > ghc-6.8.2. Can anybody help? > Not entirely related, but you might want to append your complaints: http://hackage.haskell.org/trac/ghc/ticket/1633 The request is for a documentation section that explains what each error means, where it comes from, why it's there and possibly also how to fix it in two or three paragraphs. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From magicloud.magiclouds at gmail.com Tue Nov 4 02:51:53 2008 From: magicloud.magiclouds at gmail.com (Magicloud) Date: Tue Nov 4 02:47:05 2008 Subject: [Haskell-cafe] Problem while compiling ghc 6.8 Message-ID: <490FFF19.6010005@gmail.com> Hi, I got my ghc 6.8 by `darcs get --partial http://darcs.haskell.org/ghc-6.8/ghc`, and after `darcs-all get`, `sh boot`, `configure`, without any problem, I started to make it. Well, when compiling libraries/stm, it reports "Control/Concurrent/STM/TVar.hs:22:8: Not in scope: `readTVarIO'. I tried to reget the source without '--partial', still the same. From noteed at gmail.com Tue Nov 4 02:55:27 2008 From: noteed at gmail.com (minh thu) Date: Tue Nov 4 02:50:21 2008 Subject: [Haskell-cafe] Typeable and Dynamic In-Reply-To: <694519c50811031658q2198c6bk1b9d3695786c54a8@mail.gmail.com> References: <40a414c20811031458w45b0baedybea380e146263ea2@mail.gmail.com> <694519c50811031658q2198c6bk1b9d3695786c54a8@mail.gmail.com> Message-ID: <40a414c20811032355g7a3fe3cdle6d034caf3a73c50@mail.gmail.com> 2008/11/4, Antoine Latter : > On Mon, Nov 3, 2008 at 4:58 PM, minh thu wrote: > > Hi, > > > > Given a TypeRep and a Dynamic value with type corresponding to the > > TypeRep, I'd like to be able to use fromDyn *without* specifying a type > > (given as an additional 'default' argument) (since it is somewhat known > > from the TypeRep). > > > > That is, I'd like an undefinedOf that can be used in > > > > extract :: Typeable a => TypeRep -> Dynamic -> a > > extract typerep dyn = fromDyn (undefinedOf typerep) dyn > > > > For instance, if TypeRep is Int, > > extract Int dyn = fromDyn (undefined::Int) dyn > > > > Is it possible to write "extract" ? > > > > Yep! It's already written: > > fromDynamic :: Typable a => Dynamic -> Maybe a > > It returns Nothing if the Dynamic value was of the wrong type. > > See: > > http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Dynamic.html#v:fromDynamic Well, it seems you can't really write (fromJust . fromDynamic) someDynamic without giving the type of what you expect. fromDynamic whould achieve the same thing I wrote in the previous mail if I did not write the ::Int on the right of undefined. (I would still have to write ::Int later in the code; that's what I'd like to avoid) Thanks, Thu From noteed at gmail.com Tue Nov 4 03:05:43 2008 From: noteed at gmail.com (minh thu) Date: Tue Nov 4 03:00:38 2008 Subject: [Haskell-cafe] Re: Typeable and Dynamic In-Reply-To: <20081104051602.8F2FFAE54@Adric.metnet.fnmoc.navy.mil> References: <20081104051602.8F2FFAE54@Adric.metnet.fnmoc.navy.mil> Message-ID: <40a414c20811040005q70d0da4duab1d6832672e3741@mail.gmail.com> 2008/11/4, oleg@okmij.org : > > minh thu asked a tricky question, about writing > > extract :: Typeable a => TypeRep -> Dynamic -> a > > The question here is what determines the type 'a'. One answer is that > 'a' is determined from the context, e.g., > (extract tr dyn) + 1.0 > fixes 'a' to be an Int. In that case, extract is equivalent to `read' > (indeed, String is a primitive sort of Dynamic). We do not need any > argument TypeRep though as we obtain 'a' from the context. fromDynamic > is sufficient there. > > One can also construe the question to be asking about writing an `inverse' of > typeOf. Whereas, > typeOf :: Typeable a => a -> TypeRep > can give the TypeRep for any (Typeable) type, > undefinedOf :: Typeable a => TypeRep -> a > could give (an undefined) value for a given TypeRep. Indeed, that's what I was asking. > Now, the _type_ 'a' is determined by the _value_ of TypeRep: seemingly we > need dependent types. To write function of exactly that signature, we > need Template Haskell. Oftentimes, we can get away with a weaker > function: I'll look at Template Haskell then. It's a bit cumbersome to add type annotations everywhere when using Dynamic. > > data Dyn = forall a. Typeable a => Dyn a > > reflect :: TypeRep -> Dyn > > to be used to implement dynApply, dynFst, dynSnd, dynHead and other operations > on Dynamics. Perhaps the following message may help then > http://www.haskell.org/pipermail/haskell-cafe/2007-December/036820.html Thank you, Thu From lrpalmer at gmail.com Tue Nov 4 03:27:18 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Nov 4 03:22:13 2008 Subject: [Haskell-cafe] Typeable and Dynamic In-Reply-To: <40a414c20811032355g7a3fe3cdle6d034caf3a73c50@mail.gmail.com> References: <40a414c20811031458w45b0baedybea380e146263ea2@mail.gmail.com> <694519c50811031658q2198c6bk1b9d3695786c54a8@mail.gmail.com> <40a414c20811032355g7a3fe3cdle6d034caf3a73c50@mail.gmail.com> Message-ID: <7ca3f0160811040027g3326d824h67b0b70e936a83b1@mail.gmail.com> On Mon, Nov 3, 2008 at 7:55 PM, minh thu wrote: > Well, it seems you can't really write > > (fromJust . fromDynamic) someDynamic > > without giving the type of what you expect. Well not by itself. But context will usually determine the type. For example: putStrLn . fromJust . fromDynamic $ someDynamic Will happily infer that it should cast to a String. Luke From Ivan.Miljenovic at gmail.com Tue Nov 4 03:56:58 2008 From: Ivan.Miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue Nov 4 03:52:05 2008 Subject: [Haskell-cafe] Re: ANNOUNCE: Graphalyze-0.5 and SourceGraph-0.3 References: <20081103133558.5512b2d9@gmail.com> <20081103090915.11f1d9c5@solaris> <20081104082645.159da37a@solaris> Message-ID: Achim Schneider web.de> writes: > > > That's about what I meant with a screenshot. Linking a copy of the html > generated for e.g. the Prelude would greatly help people who are just > browsing Hackage and are trying to figure out what your package is all > about. > Well, I can't do the Prelude (as I said in the original announcement, at the moment SourceGraph only works on cabalized projects, not individual files, etc.), but here's the generated reports for Graphalyze and SouceGraph themselves: http://community.haskell.org/~ivanm/Graphalyze/Graphalyze.html http://community.haskell.org/~ivanm/SourceGraph/SourceGraph.html I hope they give you a sufficient idea of what SourceGraph does. From bulat.ziganshin at gmail.com Tue Nov 4 04:23:02 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 4 04:20:04 2008 Subject: [Haskell-cafe] a minimal Windows program in Haskell? In-Reply-To: <260276.61925.qm@web57403.mail.re1.yahoo.com> References: <854180513.20081103110726@gmail.com> <260276.61925.qm@web57403.mail.re1.yahoo.com> Message-ID: <86789979.20081104122302@gmail.com> Hello Nun, Monday, November 3, 2008, 11:53:08 PM, you wrote: > 2) the Win32 package in this link gives a type error during the > "setup build" phase (expecting exception and given ioerror?) but you > can compile the example against the Win32 package in ghc 6.8.3 of course - it's written against 6.10.1. you should download sources of your GHC version and use example from it. look in http://www.haskell.org/ghc/dist/stable/dist/old -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bjorn at bringert.net Tue Nov 4 04:32:18 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Tue Nov 4 04:27:13 2008 Subject: [Haskell-cafe] Network.FastCGI does not emit stderr outputs to lighttpd's error.log? In-Reply-To: <20080731173744.GF9849@scytale.galois.com> References: <20080730175612.GC15694@scytale.galois.com> <20080731173744.GF9849@scytale.galois.com> Message-ID: On Thu, Jul 31, 2008 at 6:37 PM, Don Stewart wrote: > agentzh: >> On Thu, Jul 31, 2008 at 1:56 AM, Don Stewart wrote: >> > >> > We've had no problems with this and apache at least. Is lighttpd >> > doing something funny with error logging? >> >> It seems that Apache is doing something funny :) According to my >> teammate chaoslawful, apache redirects stderr to its error log files >> (if any) but the fastcgi spec actually says everything should go >> through the socket. And lighttpd seems to be following the spec >> exactly :) >> >> chaoslawful++ finally come up with the following patch for lighttpd >> 1.4.19 to make lighttpd behave in the same way as apache. Devel.Debug >> is now finally working for me for my Haskell fastcgi hacking :)) >> >> --- lighttpd-1.4.19/src/log.c 2007-08-22 01:40:03.000000000 +0800 >> +++ lighttpd-1.4.19-patched/src/log.c 2008-07-31 15:13:10.000000000 +0800 >> @@ -83,9 +83,14 @@ >> /* move stderr to /dev/null */ >> if (close_stderr && >> -1 != (fd = open("/dev/null", O_WRONLY))) { >> - close(STDERR_FILENO); >> + // XXX: modified by chaoslawful, don't close stderr >> when log into file >> + close(STDERR_FILENO); >> + if (srv->errorlog_mode == ERRORLOG_FILE && >> srv->errorlog_fd >=0 ) { >> + dup2(srv->errorlog_fd,STDERR_FILENO); >> + } else { >> dup2(fd, STDERR_FILENO); >> - close(fd); >> + } >> + close(fd); >> } >> return 0; >> } >> >> Best, >> -agentzh > > Interesting result, thanks for looking into this. You could also handle this issue without modifying Lighttpd by redirecting stderr to a file. Put this in your Haskell program: import System.Posix.Files import System.Posix.IO stderrToFile :: FilePath -> IO () stderrToFile file = do let mode = ownerModes `unionFileModes` groupReadMode `unionFileModes` otherReadMode fileFd <- openFd file WriteOnly (Just mode) (defaultFileFlags { append = True }) dupTo fileFd stdError return () main = do stderrToFile "my-fastcgi-log.log" runFastCGI ... Another way is to have a small wrapper shell script around your FastCGI program that does the same redirection. /Bj?rn From a.biurvOir4 at asuhan.com Tue Nov 4 05:35:04 2008 From: a.biurvOir4 at asuhan.com (Kim-Ee Yeoh) Date: Tue Nov 4 05:29:57 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: <49a77b7a0811031445s3d5558d9k5e219d7dfe1fb55d@mail.gmail.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <7ca3f0160811031349v51b28ef4tbb83d8bb04aac7f5@mail.gmail.com> <20081103215424.GZ22845@scytale.galois.com> <7ca3f0160811031402t780e1ad0sedf8201f122337bd@mail.gmail.com> <49a77b7a0811031445s3d5558d9k5e219d7dfe1fb55d@mail.gmail.com> Message-ID: <20319740.post@talk.nabble.com> David Menendez-2 wrote: > >> On Mon, 3 Nov 2008, Luke Palmer wrote: >> >> I was actually being an annoying purist. "f is strict" means "f _|_ = >> _|_", so strictness is a semantic idea, not an operational one. > > I think Luke was commenting on the terminology, not the optimization. > We have a tendency to say "lazy" when we mean "non-strict" and > "strict" when we mean "eager". > Good point. If it sheds light on such elusive, important distinctions then this incorrigible pedantry can only be encouraged. -- View this message in context: http://www.nabble.com/Problems-with-strictness-analysis--tp20301967p20319740.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From patai_gergely at fastmail.fm Tue Nov 4 06:18:21 2008 From: patai_gergely at fastmail.fm (Patai Gergely) Date: Tue Nov 4 06:13:14 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: <20081103213524.GY22845@scytale.galois.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> Message-ID: <1225797501.2283.1282885193@webmail.messagingengine.com> Thanks everyone for the answers. I understood the underlying mechanism, and I did see that turning on optimisation helps, as I said in the comments. I just wasn't aware that this analysis is not turned on by default, my bad for not reading the FM. So the final verdict is that type and strictness annotations are unavoidable when it comes to improving performance. This is no big surprise. My only problem is that if I try to write a program without thinking about performance first and not bothering with annotations as long as "it works", I end up with something that's practically impossible to profile as the costs spread everywhere. I'd be curious to hear about "best practices" to avoid this, while also getting the most out of type inference and various analyses to cut down on developer effort. How should I approach writing a large application in Haskell? Gergely -- http://www.fastmail.fm - IMAP accessible web-mail From dominic.steinitz at blueyonder.co.uk Tue Nov 4 06:26:36 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Tue Nov 4 06:22:44 2008 Subject: [Haskell-cafe] Re: Problems with strictness analysis? References: <1225715493.29387.1282684893@webmail.messagingengine.com> <490F993F.8080109@freegeek.org> Message-ID: wren ng thornton freegeek.org> writes: [snick] > > isum 0 s = s > > isum n s = isum (n-1) (s+n) > > This is tail recursive, and will be optimized to an iterative loop; [snick] > > In terms of having a compiler 'smart enough', it's not clear that > functions of this sort ought to be inferred strict simply because the > accumulator is ultimately returned to the caller. Consider for example: I thought this was strict as Luke Palmer has already pointed out. My understanding is that a compiler may be able to infer it is strict and then perform eager evaluation. > > > f 0 xs = xs > > f n xs = f (n-1) (replicate n n ++ xs) > > Since (++) can indeed return partial answers, it's fine for the > accumulator to be lazy. Indeed, making it strict harms performance > significantly. Another example is when the accumulator is a function, as Can this function be strict if (++)isn't? And if it isn't strict, why would it make sense to evaluate it eagerly? Dominic. PS This subject seems to come up often enough to be worth a wiki entry (maybe there already is one). I think we should also be careful with terminology (as Luke Palmer and David Menendez have pointed out. Maybe that could be included in the wiki entry. From ketil at malde.org Tue Nov 4 06:39:20 2008 From: ketil at malde.org (Ketil Malde) Date: Tue Nov 4 06:34:16 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: <1225797501.2283.1282885193@webmail.messagingengine.com> (Patai Gergely's message of "Tue\, 04 Nov 2008 12\:18\:21 +0100") References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <1225797501.2283.1282885193@webmail.messagingengine.com> Message-ID: <87abcfn2jb.fsf@malde.org> "Patai Gergely" writes: > My only problem is that if I try to write a program without > thinking about performance first and not bothering with annotations as > long as "it works", I end up with something that's practically > impossible to profile as the costs spread everywhere. I didn't think that was the case, does that happen with the example you posted? (I find GHC's heap profiling to be useful in tracking down these "strictness leaks".) -k -- If I haven't seen further, it is by standing in the footprints of giants From martin.hofmann at uni-bamberg.de Tue Nov 4 07:41:01 2008 From: martin.hofmann at uni-bamberg.de (Martin Hofmann) Date: Tue Nov 4 07:33:58 2008 Subject: [Haskell-cafe] code generation In-Reply-To: <20081021173242.892CB324378@www.haskell.org> References: <20081021173242.892CB324378@www.haskell.org> Message-ID: <1225802461.10942.20.camel@ios.cogsys.wiai.uni-bamberg.de> Sorry for referring to a post, a bit ago. > http://www-users.cs.york.ac.uk/~ndm/derive/ (Deriving Generic Functions > by Example). > Thanks for the pointer, it was already on my to-read-pile :-) > I think using Template Haskell for your work would fit very nicely, so > is a good choice to learn :-) > I already got used to TH a bit, but I am not sure if it is appropriate for my purpose, or at least not completely. I want to load Haskell code into my program at runtime in an abstract representation (as TH), modify it and then type-check it or coerce it into a value (or execute it). For me it looks like I need a combination of Hint and TH. However, Hint can only interpret strings and to get a string from a QExp I have to enter the IO Monad using runQ. So, wouldn't it deteriorate my performance to do it all in the IO? Is there another way? Thanks, Martin From briqueabraque at yahoo.com Tue Nov 4 07:47:17 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Tue Nov 4 07:42:33 2008 Subject: [Haskell-cafe] Syntax question regarding 'import' Message-ID: Hi, About this teste code: module Main (main) where { import Foreign hiding (unsafePerformIO,Foreign.Ptr,Data.Bits,) ; blo = xor 10 10 :: Int ; main = return () } Data.Bits is in the 'hiding' list. According to the syntax reference, this seems not to be allowed. GHC allows it, but do allow following code to use 'xor' from Data.Bits. I think this is correct, since 'xor' was exported by Foreign unqualified, but does 'Data.Bits' in that list mean something or it's just ignored? Haskell syntax allows a comma at the end of names to be imported or exported, like in the second line. What does that mean? Thanks, Maur?cio From neil.mitchell.2 at credit-suisse.com Tue Nov 4 08:33:36 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Tue Nov 4 08:29:25 2008 Subject: [Haskell-cafe] code generation In-Reply-To: <1225802461.10942.20.camel@ios.cogsys.wiai.uni-bamberg.de> References: <20081021173242.892CB324378@www.haskell.org> <1225802461.10942.20.camel@ios.cogsys.wiai.uni-bamberg.de> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C90396083A@ELON17P32001A.csfb.cs-group.com> > > I think using Template Haskell for your work would fit very > nicely, so > > is a good choice to learn :-) > > > I already got used to TH a bit, but I am not sure if it is > appropriate for my purpose, or at least not completely. > > I want to load Haskell code into my program at runtime in an > abstract representation (as TH), modify it and then > type-check it or coerce it into a value (or execute it). For > me it looks like I need a combination of Hint and TH. Perhaps. You might be able to use the GHC API to get some of what you want too. > However, Hint can only interpret strings and to get a string > from a QExp I have to enter the IO Monad using runQ. So, > wouldn't it deteriorate my performance to do it all in the > IO? Is there another way? I wouldn't worry about performance just yet. In general, Haskell code in the IO Monad is just as efficient as normal code - the IO Monad gets almost entirely optimised away by GHC. Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From bulat.ziganshin at gmail.com Tue Nov 4 08:39:15 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 4 08:34:31 2008 Subject: [Haskell-cafe] Syntax question regarding 'import' In-Reply-To: References: Message-ID: <5010077839.20081104163915@gmail.com> Hello Maur??cio, Tuesday, November 4, 2008, 3:47:17 PM, you wrote: > Haskell syntax allows a comma at the end of names > to be imported or exported, like in the second > line. What does that mean? it simplifies editiing of lists: you can add/remove lines without changing surrounding ones: import XXX hiding( aaa, bbb, ccc, ) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From barsoap at web.de Tue Nov 4 08:52:49 2008 From: barsoap at web.de (Achim Schneider) Date: Tue Nov 4 08:47:52 2008 Subject: [Haskell-cafe] Re: Syntax question regarding 'import' References: Message-ID: <20081104145249.09829403@solaris> Maur____cio wrote: > About this teste code: > > module Main (main) where { > import Foreign hiding (unsafePerformIO,Foreign.Ptr,Data.Bits,) ; > blo = xor 10 10 :: Int ; > main = return () > } > You're only hiding the typeclass Data.Bits, not the function xor. To do that, you have to write import Foreign hiding (unsafePerformIO,Data.Bits(..)) Generally, I'd use import Foo(bar, Baz, Quux(..)) as F (or even using "qualified") instead of using "hiding", it may be more verbose but is way less confusing. Actually, I usually just write import qualified Foo as F and don't ever have to worry about name clashes. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From briqueabraque at yahoo.com Tue Nov 4 11:54:24 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Tue Nov 4 11:49:30 2008 Subject: [Haskell-cafe] Re: Syntax question regarding 'import' In-Reply-To: <20081104145249.09829403@solaris> References: <20081104145249.09829403@solaris> Message-ID: >> About this teste code: >> >> module Main (main) where { >> import Foreign hiding (unsafePerformIO,Foreign.Ptr,Data.Bits,) ; >> blo = xor 10 10 :: Int ; >> main = return () >> } >> > You're only hiding the typeclass Data.Bits, not > the function xor. To do that, you have to write > > import Foreign hiding (unsafePerformIO,Data.Bits(..)) > > > Generally, I'd use (...) > import qualified Foo as F > and don't ever have to worry about name clashes. Agree. I'm asking this because I'm wrting my syntax reference. Is that a GHC extension? Look at this (from haskell 98 report sections 5.2 and 5.3): export -> qvar | qtycon [(..) | ( cname1 , ... , cnamen )] | qtycls [(..) | ( var1 , ... , varn )] | module modid import -> var | tycon [ (..) | ( cname1 , ... , cnamen )] | tycls [(..) | ( var1 , ... , varn )] It seems 'modid's are included when exporting names, but not when importing. Maur?cio From tom.davie at gmail.com Tue Nov 4 11:58:40 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Tue Nov 4 11:53:37 2008 Subject: [Haskell-cafe] announce [("InfixApplicative", 1.0), ("OpenGLCheck", 1.0), ("obj", 0.1)] Message-ID: Dear Haskellers, I've just uploaded a few packages to Hackage which I have produced while working at Anygma. I thought that people might be interested in knowing about these: obj-0.1: A library for loading and writing obj 3D models. This is still an early version and rather limited, but it's a starting point. Features: ? Load models, complete with normals, texture coordinates and materials ? Compute normals where smoothing groups are specified ? An example program to load an obj model and render it spinning on the screen. ? Faster loading that Maya itself! Bugs: ? Memory usage is rather large ? The exposed API is rather limited To Dos: ? Add support for loading groups ? Support for smooth surfaces OpenGLCheck-1.0: A micro-package containing instances of Arbitrary for the data structures provided in Graphics.Rendering.OpenGL. InfixApplicative-1.0: A second micro-package containing a pair of functions -- (<^) and (^>) which can be used to provide an infix liftA2 thus: Suppose we wanted to calculate liftA2 (+) [1,2] [2,3], but are unhappy with the fact that (+) is no longer infix, we may now use [1,2] <^(+)^> [2,3] Thanks -- any comments are greatly appreciated! Tom Davie From martijn at van.steenbergen.nl Tue Nov 4 12:05:09 2008 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Tue Nov 4 12:00:03 2008 Subject: [Haskell-cafe] Efficient parallel regular expressions Message-ID: <491080C5.2050706@van.steenbergen.nl> Hello all, For my mud client Yogurt (see hackage) I'm currently working on improving the efficiency of the hooks. Right now several hooks, each consisting of a regex and an action can be active at the same time. Every time a line of input is available (usually several times a second) I run the line through all the available regexes and execute the first matching action. I figured this is not the cleverest approach and it'd be better if I |'ed all regexes into one big DFA. However, how do I then find out which of the original hooks matched and so which action to execute? As far as I know there's no way to do that with Text.Regex. Alex looks promising but is really only an executable and doesn't offer an API. I've also found mr. Jo?o Saraiva's HaLex but I don't know if that was meant to be used seriously. Does anyone have any experience with this? What's the best way to achieve this? Thanks much, Martijn. From barsoap at web.de Tue Nov 4 12:26:06 2008 From: barsoap at web.de (Achim Schneider) Date: Tue Nov 4 12:21:08 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions References: <491080C5.2050706@van.steenbergen.nl> Message-ID: <20081104182606.498e2b28@solaris> Martijn van Steenbergen wrote: > Does anyone have any experience with this? What's the best way to > achieve this? > For anything remotely connected to parsing, always use parsec. I'd not be surprised if the beast is touring complete in itself... or can parse something that can parse itself, which'd be a reverse quine or something. (I'm going to shut up already) -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From jonathanccast at fastmail.fm Tue Nov 4 12:29:26 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Tue Nov 4 12:23:52 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions In-Reply-To: <20081104182606.498e2b28@solaris> References: <491080C5.2050706@van.steenbergen.nl> <20081104182606.498e2b28@solaris> Message-ID: <1225819766.6484.0.camel@jcchost> On Tue, 2008-11-04 at 18:26 +0100, Achim Schneider wrote: > Martijn van Steenbergen wrote: > > > Does anyone have any experience with this? What's the best way to > > achieve this? > > > For anything remotely connected to parsing, always use parsec. > > I'd not be surprised if the beast is touring complete in itself... This is an interesting question: what would constitute Turing-completeness for an EDSL, independently of the host language? jcc From neil.mitchell.2 at credit-suisse.com Tue Nov 4 12:38:45 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Tue Nov 4 12:34:04 2008 Subject: [Haskell-cafe] Efficient parallel regular expressions In-Reply-To: <491080C5.2050706@van.steenbergen.nl> References: <491080C5.2050706@van.steenbergen.nl> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C903960843@ELON17P32001A.csfb.cs-group.com> Hi Martijn, It's not that tricky if you do a regular expression state machine yourself, but that's probably a bit too much work. One way to get a speed up might be to take the regular expressions a,b,c,d and generate a regex a+b+c+d, and one a+b. You can then check any string s against a+b+c+d, if that matches check a+b, if that matches check a. At each stage you eliminate half the regular expressions, which means a match will take log n, where n is the number of regular expressions. This assumes the underlying regular expression engine constructs a finite state machine, making it O(m) where m is the length of the string to match. Thanks Neil > -----Original Message----- > From: haskell-cafe-bounces@haskell.org > [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of > Martijn van Steenbergen > Sent: 04 November 2008 5:05 pm > To: Haskell Cafe > Subject: [Haskell-cafe] Efficient parallel regular expressions > > Hello all, > > For my mud client Yogurt (see hackage) I'm currently working > on improving the efficiency of the hooks. Right now several > hooks, each consisting of a regex and an action can be active > at the same time. > Every time a line of input is available (usually several > times a second) I run the line through all the available > regexes and execute the first matching action. > > I figured this is not the cleverest approach and it'd be better if I > |'ed all regexes into one big DFA. However, how do I then > find out which > of the original hooks matched and so which action to execute? > > As far as I know there's no way to do that with Text.Regex. > Alex looks promising but is really only an executable and > doesn't offer an API. > I've also found mr. Jo?o Saraiva's HaLex but I don't know if > that was meant to be used seriously. > > Does anyone have any experience with this? What's the best > way to achieve this? > > Thanks much, > > Martijn. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From dpiponi at gmail.com Tue Nov 4 13:02:06 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Tue Nov 4 12:57:00 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions In-Reply-To: <20081104182606.498e2b28@solaris> References: <491080C5.2050706@van.steenbergen.nl> <20081104182606.498e2b28@solaris> Message-ID: <625b74080811041002t5d8a2ec4k342b663af7b6b9d2@mail.gmail.com> On Tue, Nov 4, 2008 at 9:26 AM, Achim Schneider wrote: > Martijn van Steenbergen wrote: > For anything remotely connected to parsing, always use parsec. > > I'd not be surprised if the beast is touring complete in itself... Actually, this can count against you. It's very easy to use Parsec to build an innocent looking grammar that's too slow to use because it'll do all kinds of backtracking to find a way to make your input fit the grammar. I recommend Parsec for lots of tasks, but take care to design the grammar so it doesn't take exponential time to do anything. -- Dan From sebastian.sylvan at gmail.com Tue Nov 4 14:05:59 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Tue Nov 4 14:00:56 2008 Subject: [Haskell-cafe] Memory efficiency questions for real-time graphics In-Reply-To: <221b53ab0811030745q536ee74bm5c5c0c7e6183a3ee@mail.gmail.com> References: <9c72296b0810271903s31e9cf65y9818caf189ebd7ef@mail.gmail.com> <3d96ac180810281224h69dc0fb7m2a84882bdecafa7c@mail.gmail.com> <9c72296b0811011157ke3b6815o7a69653efd8cca92@mail.gmail.com> <3d96ac180811011211j2d4bf128q42c9e606bf9cf0d7@mail.gmail.com> <9c72296b0811021110n3b4b5377hd64217052ce62d3c@mail.gmail.com> <698E8783CC407F4EB0DC9E994B6D4540CB1A83@nut.avalanchestudios.se> <221b53ab0811030745q536ee74bm5c5c0c7e6183a3ee@mail.gmail.com> Message-ID: <3d96ac180811041105v4fbd3cacl6a2704af0871da6c@mail.gmail.com> On Mon, Nov 3, 2008 at 3:45 PM, Svein Ove Aas wrote: > On Mon, Nov 3, 2008 at 11:31 AM, Tobias Bexelius > wrote: > > Before Direct3D 10, its too costly to read back the updated vertex data > > in every frame, which force you to make this kind of operations on the > > CPU. > > With D3D 10 however, you should use the new Stream-Output stage which is > > used to return updated vertex data directly to a vertex buffer on the > > GPU. So if you can afford a new graphics card and likes Vista, that's > > the way to go :) > > > Or you could use OpenGL, which has supported that since the first GPUs > that did were released. I think that came with OpenGL 3.0. Unless you're counting vendor-specific extensions... -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081104/d7beb35e/attachment.htm From barsoap at web.de Tue Nov 4 14:34:37 2008 From: barsoap at web.de (Achim Schneider) Date: Tue Nov 4 14:29:39 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions References: <491080C5.2050706@van.steenbergen.nl> <20081104182606.498e2b28@solaris> <625b74080811041002t5d8a2ec4k342b663af7b6b9d2@mail.gmail.com> Message-ID: <20081104203437.7d4b7327@solaris> "Dan Piponi" wrote: > On Tue, Nov 4, 2008 at 9:26 AM, Achim Schneider > wrote: > > Martijn van Steenbergen wrote: > > For anything remotely connected to parsing, always use parsec. > > > > I'd not be surprised if the beast is touring complete in itself... > > Actually, this can count against you. It's very easy to use Parsec to > build an innocent looking grammar that's too slow to use because it'll > do all kinds of backtracking to find a way to make your input fit the > grammar. I recommend Parsec for lots of tasks, but take care to design > the grammar so it doesn't take exponential time to do anything. > Considering that he's talking about a mud, I figure the grammar is a quite straightforward command = l[eft] | r[ight] | ... | t[ake] | c[ast] That is, I'd be very surprised if you even need more than two or three characters lookahead, much less backtracking. Parsec is a thousand times more efficient for such things than regular expressions, and you can just lazily parse all the input into a list of data constructors and happily fold it into your state... The only thing more straightforward than this is reading a xml with HaXML (if you have a DTD, that is) -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From haskell at list.mightyreason.com Tue Nov 4 15:10:48 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Tue Nov 4 15:06:00 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions In-Reply-To: <491080C5.2050706@van.steenbergen.nl> References: <491080C5.2050706@van.steenbergen.nl> Message-ID: <4910AC48.60607@list.mightyreason.com> The regex-tdfa package (and regex-posix) implement subexpressions capture. So if you want to match alpha beta and gamma in parallel you could write "(alpha)|(beta)|(gamma)" and check which subexpression has the non-empty match. This becomes slightly complicated if there are parenthesis and captures inside alpha beta or gamma. Then you need to compute the indices that are the top level captures. In particular, the regex-tdfa package (get the latest from http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-tdfa ) will create a DFA and run through the input once without backtracking. It will find the leftmost-longest match, so the order of the branches only matters if there is a tie in length. If you need to be left-biased then you need a perl-style engine, and you can use the regex-pcre or pcre-light haskell package and the PCRE library. These are obtainable from Hackage. I doubt PCRE uses a simple DFA... Cheers, Chris Martijn van Steenbergen wrote: > Hello all, > > For my mud client Yogurt (see hackage) I'm currently working on > improving the efficiency of the hooks. Right now several hooks, each > consisting of a regex and an action can be active at the same time. > Every time a line of input is available (usually several times a second) > I run the line through all the available regexes and execute the first > matching action. > > I figured this is not the cleverest approach and it'd be better if I > |'ed all regexes into one big DFA. However, how do I then find out which > of the original hooks matched and so which action to execute? > > As far as I know there's no way to do that with Text.Regex. Alex looks > promising but is really only an executable and doesn't offer an API. > I've also found mr. Jo?o Saraiva's HaLex but I don't know if that was > meant to be used seriously. > > Does anyone have any experience with this? What's the best way to > achieve this? > > Thanks much, > > Martijn. From k.pierre.k at gmail.com Tue Nov 4 15:21:42 2008 From: k.pierre.k at gmail.com (pierre) Date: Tue Nov 4 15:16:21 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions In-Reply-To: <20081104203437.7d4b7327@solaris> References: <491080C5.2050706@van.steenbergen.nl> <20081104182606.498e2b28@solaris> <625b74080811041002t5d8a2ec4k342b663af7b6b9d2@mail.gmail.com> <20081104203437.7d4b7327@solaris> Message-ID: <20081104202142.GG7102@localdomain> On Tue, Nov 04, 2008 at 08:34:37PM +0100, Achim Schneider wrote: > > Parsec is a thousand times more efficient for such things than regular > expressions, and you can just lazily parse all the input into a list > of data constructors and happily fold it into your state... I would recommend you to use parsec too; my experience suggests that parsec often results in much cleaner and readable implementation than obscure regexps. -- pierre From thiago.arrais at gmail.com Tue Nov 4 15:26:35 2008 From: thiago.arrais at gmail.com (Thiago Arrais) Date: Tue Nov 4 15:21:28 2008 Subject: [Haskell-cafe] HDBC Oracle bindings(?/!) In-Reply-To: <4909CA56.5080104@gmail.com> References: <4909CA56.5080104@gmail.com> Message-ID: On Thu, Oct 30, 2008 at 11:53 AM, Daniil Elovkov wrote: > Yes, HSQL supports Oracle natively, through OCI. hsql-oracle isn't on > hackage, only in the repository. That's exactly what I was looking for, but for HDBC instead. Since OCI bindings for HDBC don't seem to exist, I guess I'll have to write my own instead. > I don't know how Takusen's oci code looks, but I would suspect that porting > HSQL Oracle code to HDBC could be simpler, because HDBC and HSQL are quite > similar in their interfaces, unlike Takusen. Thanks for the tip. I really wasn't aware that HSQL already had OCI bindings. I'll take a look at the HSQL code, steal some ideas from it and hopefully make my little HDBC driver production ready some day. Cheers, Thiago Arrais -- Enjoy Chaos - http://blog.thiagoarrais.com Thoughts, ideas and useless ranting about software development and technology From thiago.arrais at gmail.com Tue Nov 4 15:30:25 2008 From: thiago.arrais at gmail.com (Thiago Arrais) Date: Tue Nov 4 15:25:19 2008 Subject: [Haskell-cafe] HDBC Oracle bindings(?/!) In-Reply-To: <20081030174820.GA403@hustlerturf.com> References: <20081030174820.GA403@hustlerturf.com> Message-ID: John, On Thu, Oct 30, 2008 at 2:48 PM, John Goerzen wrote: > I would certainly happily reference anyone's native Oracle HDBC > backend too, though! You may want to reference mine, given that there aren't any others currently. Just be aware that it really isn't ready for mass consumption yet. Cheers, Thiago Arrais -- Enjoy Chaos - http://blog.thiagoarrais.com Thoughts, ideas and useless ranting about software development and technology From martindemello at gmail.com Tue Nov 4 16:26:10 2008 From: martindemello at gmail.com (Martin DeMello) Date: Tue Nov 4 16:21:03 2008 Subject: [Haskell-cafe] Efficient parallel regular expressions In-Reply-To: <491080C5.2050706@van.steenbergen.nl> References: <491080C5.2050706@van.steenbergen.nl> Message-ID: On Tue, Nov 4, 2008 at 9:05 AM, Martijn van Steenbergen wrote: > > For my mud client Yogurt (see hackage) I'm currently working on > improving the efficiency of the hooks. Right now several hooks, each > consisting of a regex and an action can be active at the same time. > Every time a line of input is available (usually several times a second) > I run the line through all the available regexes and execute the first > matching action. > > I figured this is not the cleverest approach and it'd be better if I > |'ed all regexes into one big DFA. However, how do I then find out which > of the original hooks matched and so which action to execute? Is this really a problem in practice? I've done similar things in Ruby, which is a much slower language, and not had any issues - particularly in something IO bound like a MUD client it doesn't seem that running down a few tens of regexps would be a bottleneck of any sort. martin From dmehrtash at gmail.com Tue Nov 4 18:08:10 2008 From: dmehrtash at gmail.com (Daryoush Mehrtash) Date: Tue Nov 4 18:03:03 2008 Subject: [Haskell-cafe] foldl vs foldl' Message-ID: Are there cases (function or list) where the result of foldl (or foldr)would be different that foldl' (or foldr')? thanks, daryoush -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081104/5c721602/attachment.htm From barsoap at web.de Tue Nov 4 18:31:24 2008 From: barsoap at web.de (Achim Schneider) Date: Tue Nov 4 18:26:33 2008 Subject: [Haskell-cafe] Re: foldl vs foldl' References: Message-ID: <20081105003124.0fcc0707@solaris> "Daryoush Mehrtash" wrote: > Are there cases (function or list) where the result of foldl (or > foldr)would be different that foldl' (or foldr')? > Yes, in two cases folds can differ: a) You've got an infinite list, in which case you don't want to go to the end of it before starting to return values b) You don't have infinite memory and thus need things to be strict (or just don't want to pay the overhead of allocating millions of thunks for no good reason whatsoever, in case you're lucky enough to have enough memory for your data) -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From derek.a.elkins at gmail.com Tue Nov 4 18:33:21 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Nov 4 18:28:22 2008 Subject: [Haskell-cafe] foldl vs foldl' In-Reply-To: References: Message-ID: <1225841601.32339.13.camel@derek-laptop> On Tue, 2008-11-04 at 15:08 -0800, Daryoush Mehrtash wrote: > > Are there cases (function or list) where the result of foldl (or > foldr)would be different that foldl' (or foldr')? There is no foldr'. And yes, foldl and foldl' are different functions and thus return different results on some inputs; however, you almost always want foldl' (v. foldl). See http://www.haskell.org/haskellwiki/Stack_overflow From daniel.is.fischer at web.de Tue Nov 4 18:37:47 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Nov 4 18:30:25 2008 Subject: [Haskell-cafe] foldl vs foldl' In-Reply-To: References: Message-ID: <200811050037.47711.daniel.is.fischer@web.de> Am Mittwoch, 5. November 2008 00:08 schrieb Daryoush Mehrtash: > Are there cases (function or list) where the result of foldl (or > foldr)would be different that foldl' (or foldr')? > > thanks, > > daryoush Simple example: import Data.List weird :: Int -> Int -> Int weird _ 0 = 0 weird x y = x*y list :: [Int] list = [1, 2, 3, 4, undefined, 6, 7, 8, 9, 0] okey = foldl weird 1 list boom = foldl' weird 1 list *Main> okey 0 *Main> boom *** Exception: Prelude.undefined since foldl' evaluates strictly (to WHNF), it can die on encountering an undefined value in the list where foldl doesn't. From derek.a.elkins at gmail.com Tue Nov 4 18:40:07 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Nov 4 18:35:06 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions In-Reply-To: <625b74080811041002t5d8a2ec4k342b663af7b6b9d2@mail.gmail.com> References: <491080C5.2050706@van.steenbergen.nl> <20081104182606.498e2b28@solaris> <625b74080811041002t5d8a2ec4k342b663af7b6b9d2@mail.gmail.com> Message-ID: <1225842007.32339.22.camel@derek-laptop> On Tue, 2008-11-04 at 10:02 -0800, Dan Piponi wrote: > On Tue, Nov 4, 2008 at 9:26 AM, Achim Schneider wrote: > > Martijn van Steenbergen wrote: > > For anything remotely connected to parsing, always use parsec. > > > > I'd not be surprised if the beast is touring complete in itself... > > Actually, this can count against you. It's very easy to use Parsec to > build an innocent looking grammar that's too slow to use because it'll > do all kinds of backtracking to find a way to make your input fit the > grammar. I recommend Parsec for lots of tasks, but take care to design > the grammar so it doesn't take exponential time to do anything. Backtracking points are explicit in Parsec which is one of the whole points of it. This makes it pretty difficult to "innocently" end up with exponential behavior. Backtracking requires a use of the 'try' combinator. It's pretty easy to recognize potentially dangerous uses of 'try'. If you use 'try' willy-nilly or you just throw 'try' in when you are having difficulties then I can quite easily imagine one quickly ending up with exponential behavior. Otherwise, it should not be "easy" to do and if you like you can not use 'try' (or 'try' using combinators) at all and you surely won't get exponential behavior (as far as Parsec is concerned). From derek.a.elkins at gmail.com Tue Nov 4 18:41:14 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Nov 4 18:36:14 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: <1225797501.2283.1282885193@webmail.messagingengine.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <1225797501.2283.1282885193@webmail.messagingengine.com> Message-ID: <1225842074.32339.23.camel@derek-laptop> On Tue, 2008-11-04 at 12:18 +0100, Patai Gergely wrote: > Thanks everyone for the answers. I understood the underlying mechanism, > and I did see that turning on optimisation helps, as I said in the > comments. I just wasn't aware that this analysis is not turned on by > default, my bad for not reading the FM. > > So the final verdict is that type and strictness annotations are > unavoidable when it comes to improving performance. This is no big > surprise. My only problem is that if I try to write a program without > thinking about performance first and not bothering with annotations as > long as "it works", I end up with something that's practically > impossible to profile as the costs spread everywhere. I'd be curious to > hear about "best practices" to avoid this, while also getting the most > out of type inference and various analyses to cut down on developer > effort. How should I approach writing a large application in Haskell? Strictness annotations aren't optimizations. As Luke Palmer pointed out, making something strict is a change in semantics. Similarly for type annotations; either they do nothing or they restrict the type which certainly has semantic ramifications. Neither strictness nor type annotations should be viewed as something "outside of" your program. They are a part of your program. At any rate, for the particular issues you've mentioned in this thread I'd recommend not writing code you "know" is bad in the first place, in much the same way that Scheme programmers usually write code tail recursively from the start. They don't write code (non tail) recursively and then "profile" to find the hotspots. There are a few well-known problematic patterns in Haskell that can be relatively easily recognized and remedied. Those should be dealt with as you write the code. Note that here I'm talking about issues like stack overflow; you shouldn't rely on strictness analysis to avoid stack overflow, but it is fine to rely on strictness analysis for things like unboxing and such. Basically, if you don't do "stupid stuff", such as well-known anti-patterns or obviously inefficient things, then you should typically get reasonable performance with maybe a few things that the profiler can help you with. If you are specifically going for performance, then there are techniques and approaches geared toward that. From v.dijk.bas at gmail.com Tue Nov 4 18:43:37 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Tue Nov 4 18:38:28 2008 Subject: [Haskell-cafe] foldl vs foldl' In-Reply-To: References: Message-ID: 2008/11/5 Daryoush Mehrtash : > Are there cases (function or list) where the result of foldl (or foldr)would > be different that foldl' (or foldr')? Maybe this wiki article I wrote some time ago will answer your question: http://haskell.org/haskellwiki/Foldr_Foldl_Foldl' regards, Bas From v.dijk.bas at gmail.com Tue Nov 4 18:45:44 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Tue Nov 4 18:40:36 2008 Subject: [Haskell-cafe] foldl vs foldl' In-Reply-To: References: Message-ID: On Wed, Nov 5, 2008 at 12:43 AM, Bas van Dijk wrote: > 2008/11/5 Daryoush Mehrtash : >> Are there cases (function or list) where the result of foldl (or foldr)would >> be different that foldl' (or foldr')? > > Maybe this wiki article I wrote some time ago will answer your question: > > http://haskell.org/haskellwiki/Foldr_Foldl_Foldl' Oops that link should be: http://haskell.org/haskellwiki/Foldr_Foldl_Foldl%27 From lennart at augustsson.net Tue Nov 4 18:52:36 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Nov 4 18:47:29 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: <20081103213524.GY22845@scytale.galois.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> Message-ID: Nonsense, isum is strict in s. If s is bottom, isum will always return bottom. This is the definition of being strict. -- Lennart On Mon, Nov 3, 2008 at 10:35 PM, Don Stewart wrote: > frantisek.kocun: >> yet I need to add a $! to the recursive call of isum to get a truly >> iterative ??? >> >> Wait a minute Patai. How would you do that? I'm only beginner I thought I >> can only add strict "!" to data parameters. But to make isum function >> strict would be helpful. >> > > Consider this program, > > isum 0 s = s > isum n s = isum (n-1) (s+n) > > main = case isum 10000000 0 {- rsum 10000000 -} of > 0 -> print 0 > x -> print x > > Now, isum is *not* strict in 's', so without some additional hints or analysis, this > won't be evaluated until the result of isum is required. It will build up a long change of (s + n) > on the stack. > > -O0 > $ time ./A > Stack space overflow: current size 8388608 bytes. > > Of course, we make this strict in a number of ways: > > > * Turning on optimisations: > -O2 > $ time ./A > 50000005000000 > ./A 0.31s user 0.00s system 99% cpu 0.312 total > > * Use an explict bang pattern on the 's' variable: > > {-# LANGUAGE BangPatterns #-} > > isum 0 s = s > isum n !s = isum (n-1) (s+n) > > -O0 > $ time ./A > 50000005000000 > ./A 0.69s user 0.00s system 95% cpu 0.721 total > > Note that by being explict about the strictness in 's' this program produces the desired result > even with all optimisations disabled. > > We can then turn on other optimisations: > > -O2 -fvia-C -optc-O2 > $ time ./A > 50000005000000 > ./A 0.31s user 0.00s system 101% cpu 0.313 total > > And it just gets faster. > > Now, we can also add an explicit type signature to constrain to a machine Int: > > -O2 -fvia-C -optc-O2 > $ time ./A > 50000005000000 > ./A 0.03s user 0.00s system 100% cpu 0.033 total > > Meaing the final version is: > > isum :: Int -> Int -> Int > isum 0 s = s > isum n !s = isum (n-1) (s+n) > > So: if you rely on tail recursion on a particular variable, make sure it is > enforced as strict. That's the simplest, most robust way to ensure the > reduction strategy you want is used. > > -- Don > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jason.dusek at gmail.com Tue Nov 4 19:12:29 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Tue Nov 4 19:07:22 2008 Subject: [Haskell-cafe] pure programs Message-ID: <42784f260811041612i62346327uc8dd5ae919aea43f@mail.gmail.com> Informally, a "pure program" an executable such that the stream of bytes entering it totally determines the stream of bytes leaving it. Many useful programs that I would like to write in Haskell don't fall into this category -- for example, network servers -- but a lot of their components do. Can these components can be Haskell functions without IO in their signatures? Though that seems reasonable, it is not, in general, true. For example, System.Info.os is generally treated as pure, though it is not. It's not clear to me how to disambiguate these "born again" values from really pure values. -- _jsn From jamiiecb at googlemail.com Tue Nov 4 19:26:56 2008 From: jamiiecb at googlemail.com (Jamie Brandon) Date: Tue Nov 4 19:21:51 2008 Subject: [Haskell-cafe] pure programs In-Reply-To: <42784f260811041612i62346327uc8dd5ae919aea43f@mail.gmail.com> References: <42784f260811041612i62346327uc8dd5ae919aea43f@mail.gmail.com> Message-ID: <10ed1a750811041626w145b91cfr2e90322773afd3ff@mail.gmail.com> You're essentially describing functional reactive programming. You end up with the system being described as pure, reactive values and plugging IO based streams in at the edges. Have a look at the wiki description (http://www.haskell.org/haskellwiki/Functional_Reactive_Programming) and especially the Reactive library (http://www.haskell.org/haskellwiki/Reactive). Theres been a fair amount of work on using frp for distributed, network-orientated systems. Flask (http://portal.acm.org/citation.cfm?id=1411203.1411251) and Opis (http://perso.eleves.bretagne.ens-cachan.fr/~dagand/opis/) are particularly interesting. Opis really shows the value of using pure functions by allowing the same reactive system to be run in production, attached to a debugger, run in a step-by-step simulator or run in a model checker without altering the systems code. On Wed, Nov 5, 2008 at 12:12 AM, Jason Dusek wrote: > Informally, a "pure program" an executable such that the > stream of bytes entering it totally determines the stream of > bytes leaving it. > > Many useful programs that I would like to write in Haskell > don't fall into this category -- for example, network servers > -- but a lot of their components do. Can these components can > be Haskell functions without IO in their signatures? > > Though that seems reasonable, it is not, in general, true. For > example, System.Info.os is generally treated as pure, > though it is not. It's not clear to me how to disambiguate > these "born again" values from really pure values. > > -- > _jsn > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From allbery at ece.cmu.edu Tue Nov 4 19:37:12 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Nov 4 19:32:09 2008 Subject: [Haskell-cafe] pure programs In-Reply-To: <42784f260811041612i62346327uc8dd5ae919aea43f@mail.gmail.com> References: <42784f260811041612i62346327uc8dd5ae919aea43f@mail.gmail.com> Message-ID: On 2008 Nov 4, at 19:12, Jason Dusek wrote: > Many useful programs that I would like to write in Haskell > don't fall into this category -- for example, network servers > -- but a lot of their components do. Can these components can > be Haskell functions without IO in their signatures? I'm working on a report generator (for my own use, probably will be too limited for practical use until/unless I have a need); the input data and output ultimately have to be in IO, but the bulk of the program (and all of the library) is pure; you *want* a report to produce the same output for the same input. -- 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 goofyheadedpunk at gmail.com Tue Nov 4 20:04:43 2008 From: goofyheadedpunk at gmail.com (Brian Troutwine) Date: Tue Nov 4 19:59:36 2008 Subject: [Haskell-cafe] HXT/Practical/Weather.hs difficulties Message-ID: <971980cc0811041704t316ca42bo810a57a274ec145b@mail.gmail.com> Hello all, I'm working through the practical HXT examples and have gotten stumped with the weather example[1]. I'm using GHC 6.8.3 and HXT 8.1.0. I compile the example like so... > blt@doritos:~ > $ ghc --make weather.hs > [1 of 1] Compiling Main ( weather.hs, weather.o ) > Linking weather ... And execute it... > blt@doritos:~ > $ ./weather > > error: "" unexpected "P" > expecting white space, "[" or ">" > > Unable to parse weather data. Woops. Would someone be so kind as to explain why this is failing? I'm at rather a loss. [1] http://www.haskell.org/haskellwiki/HXT/Practical/Weather1 --Brian P.S. Is this question better suited to the haskell-beginner list? From goofyheadedpunk at gmail.com Tue Nov 4 20:50:20 2008 From: goofyheadedpunk at gmail.com (Brian Troutwine) Date: Tue Nov 4 20:45:12 2008 Subject: [Haskell-cafe] HXT/Practical/Weather.hs difficulties In-Reply-To: <1225848504.6772.8.camel@porges-laptop> References: <971980cc0811041704t316ca42bo810a57a274ec145b@mail.gmail.com> <1225848504.6772.8.camel@porges-laptop> Message-ID: <971980cc0811041750ye5421e4kf6741db48bf6747b@mail.gmail.com> Oh my, how silly of me. The page has moved to http://www.weather.gov/xml/current_obs/KAGC.xml ! Firefox simply follows the redirect. Thanks for the putStrLn suggestion, George. On Tue, Nov 4, 2008 at 5:28 PM, George Pollard wrote: > On Tue, 2008-11-04 at 17:04 -0800, Brian Troutwine wrote: >> > blt@doritos:~ >> > $ ./weather >> > >> > error: ""> > unexpected "P" >> > expecting white space, "[" or ">" >> > >> > Unable to parse weather data. >> >> Woops. Would someone be so kind as to explain why this is failing? I'm >> at rather a loss. > > The HXT parser is stopping because it's expecting XML not HTML, which is > what you're receiving for some reason. > > I just loaded up the weather URL in Firefox > [http://www.weather.gov/xml/current_obs/KAGC.xml] and it is XML... Is it > possible that you are behind a proxy that is blocking the page? (I can't > run the code at the moment; cleaning out Haskell packages to upgrade to > 6.10.) > > You could try printing out the contents of the page as well (putStrLn > doc) so you can see the rest of the HTML that `weather` is receiving. > -- Brian From ajb at spamcop.net Tue Nov 4 21:52:20 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Tue Nov 4 21:47:16 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions In-Reply-To: <20081104203437.7d4b7327@solaris> References: <491080C5.2050706@van.steenbergen.nl> <20081104182606.498e2b28@solaris> <625b74080811041002t5d8a2ec4k342b663af7b6b9d2@mail.gmail.com> <20081104203437.7d4b7327@solaris> Message-ID: <20081104215220.zzuem1vgg00kkkwg-nwo@webmail.spamcop.net> G'day all. Quoting Achim Schneider : > Considering that he's talking about a mud, I figure the grammar is a > quite straightforward > > command = l[eft] | r[ight] | ... | t[ake] | c[ast] > > That is, I'd be very surprised if you even need more than two or three > characters lookahead, much less backtracking. In the case of a command followed by arguments, it would make more sense to use a keyword recogniser followed by a command-specific parser. One suggestion follows. Cheers, Andrew Bromage --------8<---CUT HERE---8<-------- module KeywordMatch (keywordMatch) where import Data.List import Data.Function import Control.Arrow -- Exercise: Why would it be wrong to curry this function? keywordMatch :: (Ord k) => [([k],v)] -> [k] -> Maybe v keywordMatch kvs = compileTrie . generateTrie . sortBy (compare `on` fst) $ kvs data Trie k v = Trie (Maybe v) (Trie' k v) data Trie' k v = Node0 | Node1 k (Trie k v) | Node2 k (Trie k v) k (Trie k v) | Branch k (Trie' k v) (Trie k v) (Trie' k v) generateTrie :: (Ord k) => [([k],v)] -> Trie k v generateTrie (([],v):rest) = Trie (Just v) (generateTrie' rest) generateTrie rest = Trie Nothing (generateTrie' rest) generateTrie' :: (Ord k) => [([k],v)] -> Trie' k v generateTrie' [] = Node0 generateTrie' [(k:ks,v)] = Node1 k $ foldr (\k -> Trie Nothing . Node1 k) (Trie (Just v) Node0) ks generateTrie' [(k1:ks1,v1),(k2:ks2,v2)] = Node2 k1 (generateTrie [(ks1,v1)]) k2 (generateTrie [(ks2,v2)]) generateTrie' kvs = gt . map (head.fst.head &&& map (first tail)) . groupBy ((==) `on` head.fst) $ kvs where gt [] = Node0 gt [(k,kvs)] = Node1 k (generateTrie kvs) gt [(k1,kvs1),(k2,kvs2)] = Node2 k1 (generateTrie kvs1) k2 (generateTrie kvs2) gt kvs = let (l,(k,m):r) = splitAt (length kvs `div` 2) kvs in Branch k (gt l) (generateTrie m) (gt r) compileTrie :: (Ord k) => Trie k v -> [k] -> Maybe v compileTrie (Trie emptyCase trie') = let ctrie' = compileTrie' trie' in \key -> case key of [] -> emptyCase (k:ks) -> ctrie' k ks compileTrie' :: (Ord k) => Trie' k v -> k -> [k] -> Maybe v compileTrie' Node0 = \k ks -> Nothing compileTrie' (Node1 k' t) = let t' = compileTrie t in \k ks -> if k == k' then t' ks else Nothing compileTrie' (Node2 k1 t1 k2 t2) = let t1' = compileTrie t1 t2' = compileTrie t2 in \k ks -> if k == k1 then t1' ks else if k == k2 then t2' ks else Nothing compileTrie' (Branch k' l m r) = let cl = compileTrie' l cm = compileTrie m cr = compileTrie' r in \k ks -> case compare k k' of LT -> cl k ks EQ -> cm ks GT -> cr k ks -- vim: ts=4:sts=4:expandtab From ajb at spamcop.net Tue Nov 4 21:59:03 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Tue Nov 4 21:53:58 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions In-Reply-To: <20081104203437.7d4b7327@solaris> References: <491080C5.2050706@van.steenbergen.nl> <20081104182606.498e2b28@solaris> <625b74080811041002t5d8a2ec4k342b663af7b6b9d2@mail.gmail.com> <20081104203437.7d4b7327@solaris> Message-ID: <20081104215903.u428f9np0kcko48w-nwo@webmail.spamcop.net> G'day all. Quoting Achim Schneider : > Considering that he's talking about a mud, I figure the grammar is a > quite straightforward > > command = l[eft] | r[ight] | ... | t[ake] | c[ast] > > That is, I'd be very surprised if you even need more than two or three > characters lookahead, much less backtracking. In the case of a command followed by arguments, it would make more sense to use a keyword recogniser followed by a command-specific parser. One suggestion follows. Cheers, Andrew Bromage --------8<---CUT HERE---8<-------- module KeywordMatch (keywordMatch) where import Data.List import Data.Function import Control.Arrow -- Exercise: Why would it be wrong to curry this function? keywordMatch :: (Ord k) => [([k],v)] -> [k] -> Maybe v keywordMatch kvs = compileTrie . generateTrie . sortBy (compare `on` fst) $ kvs data Trie k v = Trie (Maybe v) (Trie' k v) data Trie' k v = Node0 | Node1 k (Trie k v) | Node2 k (Trie k v) k (Trie k v) | Branch k (Trie' k v) (Trie k v) (Trie' k v) generateTrie :: (Ord k) => [([k],v)] -> Trie k v generateTrie (([],v):rest) = Trie (Just v) (generateTrie' rest) generateTrie rest = Trie Nothing (generateTrie' rest) generateTrie' :: (Ord k) => [([k],v)] -> Trie' k v generateTrie' [] = Node0 generateTrie' [(k:ks,v)] = Node1 k $ foldr (\k -> Trie Nothing . Node1 k) (Trie (Just v) Node0) ks generateTrie' [(k1:ks1,v1),(k2:ks2,v2)] = Node2 k1 (generateTrie [(ks1,v1)]) k2 (generateTrie [(ks2,v2)]) generateTrie' kvs = gt . map (head.fst.head &&& map (first tail)) . groupBy ((==) `on` head.fst) $ kvs where gt [] = Node0 gt [(k,kvs)] = Node1 k (generateTrie kvs) gt [(k1,kvs1),(k2,kvs2)] = Node2 k1 (generateTrie kvs1) k2 (generateTrie kvs2) gt kvs = let (l,(k,m):r) = splitAt (length kvs `div` 2) kvs in Branch k (gt l) (generateTrie m) (gt r) compileTrie :: (Ord k) => Trie k v -> [k] -> Maybe v compileTrie (Trie emptyCase trie') = let ctrie' = compileTrie' trie' in \key -> case key of [] -> emptyCase (k:ks) -> ctrie' k ks compileTrie' :: (Ord k) => Trie' k v -> k -> [k] -> Maybe v compileTrie' Node0 = \k ks -> Nothing compileTrie' (Node1 k' t) = let t' = compileTrie t in \k ks -> if k == k' then t' ks else Nothing compileTrie' (Node2 k1 t1 k2 t2) = let t1' = compileTrie t1 t2' = compileTrie t2 in \k ks -> if k == k1 then t1' ks else if k == k2 then t2' ks else Nothing compileTrie' (Branch k' l m r) = let cl = compileTrie' l cm = compileTrie m cr = compileTrie' r in \k ks -> case compare k k' of LT -> cl k ks EQ -> cm ks GT -> cr k ks -- vim: ts=4:sts=4:expandtab From chad.scherrer at gmail.com Tue Nov 4 22:34:01 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Tue Nov 4 22:29:05 2008 Subject: [Haskell-cafe] Re: Automatic parallelism in Haskell, similar to "make -j4"? References: <9c72296b0811021528w596e07b4pbd8ed46cdd7ef6c6@mail.gmail.com> Message-ID: T Willingham gmail.com> writes: > I am thinking of our troglodytic friend 'make', which will run (for > example) 4 parallel jobs when given the option "make -j4". Even > 'rake', the ruby version of make, now has a branch (called drake) > which does the parallel -j option. >From the replies I've seen about this, I think it's been interpreted as asking whether ghc could compile a given program so that it will execute in parallel. In general that's a hard problem. On the other hand, it should be really straightforward (in principle, I mean) to get something going like ghc --make -j4 Foo.hs similar to your make example, so that compile time could be reduced, while the execution could either be sequential or parallel. I don't think there's anything like this yet (is there?). Does anyone have any thought what it would take to get this going? Chad From alexander.dunlap at gmail.com Tue Nov 4 23:09:51 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Tue Nov 4 23:04:43 2008 Subject: [Haskell-cafe] Re: Automatic parallelism in Haskell, similar to "make -j4"? In-Reply-To: References: <9c72296b0811021528w596e07b4pbd8ed46cdd7ef6c6@mail.gmail.com> Message-ID: <57526e770811042009n447a205w9cd9324453df48be@mail.gmail.com> On Tue, Nov 4, 2008 at 7:34 PM, Chad Scherrer wrote: > T Willingham gmail.com> writes: >> I am thinking of our troglodytic friend 'make', which will run (for >> example) 4 parallel jobs when given the option "make -j4". Even >> 'rake', the ruby version of make, now has a branch (called drake) >> which does the parallel -j option. > > >From the replies I've seen about this, I think it's been interpreted as asking > whether ghc could compile a given program so that it will execute in parallel. > In general that's a hard problem. > > On the other hand, it should be really straightforward (in principle, I mean) to > get something going like > ghc --make -j4 Foo.hs > similar to your make example, so that compile time could be reduced, while the > execution could either be sequential or parallel. I don't think there's anything > like this yet (is there?). > > Does anyone have any thought what it would take to get this going? > > Chad I believe that's the one of the points of the hbuild project (see http://hackage.haskell.org/trac/hackage/wiki/HBuild). Alex From cetin.sert at gmail.com Wed Nov 5 00:34:14 2008 From: cetin.sert at gmail.com (Cetin Sert) Date: Wed Nov 5 00:29:06 2008 Subject: [Haskell-cafe] view patterns Message-ID: <1ff5dedc0811042134x3e5c3f67ld12408c54037a629@mail.gmail.com> let has [] = False; has _ = True -- this one is ok let empty list = case has list of True -> False; False -> True -- the following is problematic let emp (has -> True) = False; emp (has -> False) = True :1:4: Warning: Pattern match(es) are overlapped In the definition of `emp': emp ((has -> True)) = ... emp ((has -> False)) = ... Why do I get this error in ghc or when I try to compile a file with view patterns? (using -fglasgow-exts and -XViewPatterns, ghc 6.10.1) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081105/619ee876/attachment.htm From bulat.ziganshin at gmail.com Wed Nov 5 02:52:19 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Nov 5 02:51:26 2008 Subject: [Haskell-cafe] pure programs In-Reply-To: <42784f260811041612i62346327uc8dd5ae919aea43f@mail.gmail.com> References: <42784f260811041612i62346327uc8dd5ae919aea43f@mail.gmail.com> Message-ID: <1625100027.20081105105219@gmail.com> Hello Jason, Wednesday, November 5, 2008, 3:12:29 AM, you wrote: > Many useful programs that I would like to write in Haskell > don't fall into this category -- for example, network servers > -- but a lot of their components do. Can these components can > be Haskell functions without IO in their signatures? pure function is one those result depends only on its arguments. as far as you can provide "input stream" as an function argument, it should be possible to write it in pure way (as far as you don't concern efficiency. sometimes imperative algorithms mauy be just faster than pure ones since data structures are different) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Wed Nov 5 02:54:25 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Nov 5 02:51:33 2008 Subject: [Haskell-cafe] Re: Automatic parallelism in Haskell, similar to "make -j4"? In-Reply-To: References: <9c72296b0811021528w596e07b4pbd8ed46cdd7ef6c6@mail.gmail.com> Message-ID: <1976563267.20081105105425@gmail.com> Hello Chad, Wednesday, November 5, 2008, 6:34:01 AM, you wrote: > ghc --make -j4 Foo.hs afair, it was implemented and not shown speed improvements. ask Simon -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Wed Nov 5 02:55:33 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Nov 5 02:51:39 2008 Subject: [Haskell-cafe] view patterns In-Reply-To: <1ff5dedc0811042134x3e5c3f67ld12408c54037a629@mail.gmail.com> References: <1ff5dedc0811042134x3e5c3f67ld12408c54037a629@mail.gmail.com> Message-ID: <1467355940.20081105105533@gmail.com> Hello Cetin, Wednesday, November 5, 2008, 8:34:14 AM, you wrote: > let emp (has -> True) = False; emp (has -> False) = True > ??? Warning: Pattern match(es) are overlapped proibably it's because GHC can't check view patterns for overlaps? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From kr.angelov at gmail.com Wed Nov 5 03:35:16 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Wed Nov 5 03:30:07 2008 Subject: [Haskell-cafe] Efficient parallel regular expressions In-Reply-To: <491080C5.2050706@van.steenbergen.nl> References: <491080C5.2050706@van.steenbergen.nl> Message-ID: Hi Martijn, If you are brave to start implementing DFA with all required optimisations then you might want to look at: http://www.ontotext.com/gate/japec.html This is a compiler for language called JAPE. In the language you define a set of rules where the right hand side is a regular expression and the left hand side is a Java code. The compiler itself is implemented in Haskell. It includes code to build DFA from the set of regexps and then it does determinization and minimization. I wrote the compiler few years ago. You can decide to take and change the code or to reimplement it yourself. Definitely DFA guarantees that the performance is always linear while with Parsec you have to be careful. Regards, Krasimir On Tue, Nov 4, 2008 at 6:05 PM, Martijn van Steenbergen wrote: > Hello all, > > For my mud client Yogurt (see hackage) I'm currently working on > improving the efficiency of the hooks. Right now several hooks, each > consisting of a regex and an action can be active at the same time. > Every time a line of input is available (usually several times a second) > I run the line through all the available regexes and execute the first > matching action. > > I figured this is not the cleverest approach and it'd be better if I > |'ed all regexes into one big DFA. However, how do I then find out which > of the original hooks matched and so which action to execute? > > As far as I know there's no way to do that with Text.Regex. Alex looks > promising but is really only an executable and doesn't offer an API. > I've also found mr. Jo?o Saraiva's HaLex but I don't know if that was > meant to be used seriously. > > Does anyone have any experience with this? What's the best way to > achieve this? > > Thanks much, > > Martijn. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From g9ks157k at acme.softbase.org Wed Nov 5 03:43:50 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Nov 5 03:38:42 2008 Subject: [Haskell-cafe] Making 'community' server our social network In-Reply-To: References: Message-ID: <200811050943.50638.g9ks157k@acme.softbase.org> Am Montag, 3. November 2008 02:43 schrieb Maur??cio: > Hi, > > I've beeing doing something with darcs that is so great that, > although I'm sure a lot of people are already doing the same, I > think it would be nice to share with you. I did 'cd ~' and then: > > darcs initialize > darcs add .emacs > darcs add .xmonad/xmonad.hs > darcs add .inputrc > ... > etc. > > So I'm using darcs to keep track of all my configuration files, > and now I don't need to care about reinstalling the OS, changing > machines from office to home, changing configurations and then > realizing it was a mistake etc. > > Then I thought community.haskell.org could offer a default darcs > repositories for all users named after their owners. For instance, > if you want to check my personal files you would do: > > darcs get http://code.haskell.org/MauricioAntunes > > That would allow us not only to share our configuration, but also > share all those small files that are not "professional" enough > to became projects for their own, but that are nevertheless > interesting since we put our good ideas there: scripts to start > our favorite software or do system maintenance; small Haskell > utilities to do some cool math or science trick, stress some > language feature or download our standard music collection from > the web; a list of favorite sites and a related completion script > so we can list then in 'dmenu' completion; etc. etc. etc. > > The next bonus step would be to get a list at all users default > repository main page of all other users they have granted write > access to some of their projects. Then we would be able to > navigate throw linked lists of people with related interests and > needs. > > I think we need no more to get what will be MySpace, Facebook or > something else for text-driven people. And then, of course, world > domination. Although I don't really imagine any business model > around that :) > > Best, > Maur?cio So your idea means that I have to store all my configuration files etc. in a single darcs repository? Not a nice idea, in my opinion. I already use darcs for synchronizing data between my work and home computer but I use several repositories for several topics. A topic would be something like a lecture I write exercises for or a conference I write a paper for. Best wishes, Wolfgang From agocorona at gmail.com Wed Nov 5 03:52:54 2008 From: agocorona at gmail.com (Alberto G. Corona ) Date: Wed Nov 5 03:47:44 2008 Subject: [Haskell-cafe] pure programs In-Reply-To: <1625100027.20081105105219@gmail.com> References: <42784f260811041612i62346327uc8dd5ae919aea43f@mail.gmail.com> <1625100027.20081105105219@gmail.com> Message-ID: A performance improvement could be the caching of responses based on computation costs and number of accesses. This functionality can be implemented a general module that may be used to wrap any pure program if needed. This is something that only pure programs can ever do. And the haskell type system can enforce that. 2008/11/5 Bulat Ziganshin > Hello Jason, > > Wednesday, November 5, 2008, 3:12:29 AM, you wrote: > > > Many useful programs that I would like to write in Haskell > > don't fall into this category -- for example, network servers > > -- but a lot of their components do. Can these components can > > be Haskell functions without IO in their signatures? > > pure function is one those result depends only on its arguments. as > far as you can provide "input stream" as an function argument, it > should be possible to write it in pure way (as far as you don't > concern efficiency. sometimes imperative algorithms mauy be just > faster than pure ones since data structures are different) > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081105/64c91cd0/attachment.htm From barsoap at web.de Wed Nov 5 04:02:02 2008 From: barsoap at web.de (Achim Schneider) Date: Wed Nov 5 03:57:05 2008 Subject: [Haskell-cafe] Re: Problems with strictness analysis? References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <1225797501.2283.1282885193@webmail.messagingengine.com> <1225842074.32339.23.camel@derek-laptop> Message-ID: <20081105100202.7156dc52@solaris> Derek Elkins wrote: > well-known anti-patterns > I'm wondering why there are so miraculously well-known. Could it be the dedicated wiki page titled "DONTDOTHAT!!!one!" that lists them all? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From barsoap at web.de Wed Nov 5 04:15:48 2008 From: barsoap at web.de (Achim Schneider) Date: Wed Nov 5 04:10:50 2008 Subject: [Haskell-cafe] Re: pure programs References: <42784f260811041612i62346327uc8dd5ae919aea43f@mail.gmail.com> Message-ID: <20081105101548.7bda8171@solaris> "Jason Dusek" wrote: > Can these components can > be Haskell functions without IO in their signatures? > Sure. You might, for example, abstract networking out of your web server and thus end up with a function of type serve :: [HTTPRequest] -> [HTTPResponse] that lazily maps its input stream to an output stream. You can keep state by passing your state to yourself in a recursive call or do something more involved like using the state monad, but you'll find it very, very, very hard to write a genuinely non-deterministic program without changing input data, no matter what you do, even on multiprocessors. Enabling such things seems rather to be the scope of INTERCAL... does it already have a MAYBE COME FROM statement that relies on an external random source? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From tobias.bexelius at avalanchestudios.se Wed Nov 5 05:08:16 2008 From: tobias.bexelius at avalanchestudios.se (Tobias Bexelius) Date: Wed Nov 5 05:03:09 2008 Subject: [Haskell-cafe] Memory efficiency questions for real-time graphics In-Reply-To: <3d96ac180811041105v4fbd3cacl6a2704af0871da6c@mail.gmail.com> References: <9c72296b0810271903s31e9cf65y9818caf189ebd7ef@mail.gmail.com> <3d96ac180810281224h69dc0fb7m2a84882bdecafa7c@mail.gmail.com> <9c72296b0811011157ke3b6815o7a69653efd8cca92@mail.gmail.com> <3d96ac180811011211j2d4bf128q42c9e606bf9cf0d7@mail.gmail.com> <9c72296b0811021110n3b4b5377hd64217052ce62d3c@mail.gmail.com> <698E8783CC407F4EB0DC9E994B6D4540CB1A83@nut.avalanchestudios.se> <221b53ab0811030745q536ee74bm5c5c0c7e6183a3ee@mail.gmail.com> <3d96ac180811041105v4fbd3cacl6a2704af0871da6c@mail.gmail.com> Message-ID: <698E8783CC407F4EB0DC9E994B6D4540D02657@nut.avalanchestudios.se> I believe Svein is thinking of render-to-texture which indeed could be used to emulate Stream-Out functionality (but with reduced performance of course). This is also hardware specific and was still not supported on the first GPU's. ________________________________ From: Sebastian Sylvan [mailto:sebastian.sylvan@gmail.com] Sent: den 4 november 2008 20:06 To: sveina@gmail.com Cc: Tobias Bexelius; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Memory efficiency questions for real-time graphics On Mon, Nov 3, 2008 at 3:45 PM, Svein Ove Aas wrote: On Mon, Nov 3, 2008 at 11:31 AM, Tobias Bexelius wrote: > Before Direct3D 10, its too costly to read back the updated vertex data > in every frame, which force you to make this kind of operations on the > CPU. > With D3D 10 however, you should use the new Stream-Output stage which is > used to return updated vertex data directly to a vertex buffer on the > GPU. So if you can afford a new graphics card and likes Vista, that's > the way to go :) > Or you could use OpenGL, which has supported that since the first GPUs that did were released. I think that came with OpenGL 3.0. Unless you're counting vendor-specific extensions... -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081105/929909ab/attachment.htm From mad.one at gmail.com Wed Nov 5 05:11:33 2008 From: mad.one at gmail.com (Austin Seipp) Date: Wed Nov 5 05:06:25 2008 Subject: [Haskell-cafe] Re: Automatic parallelism in Haskell, similar to "make -j4"? In-Reply-To: References: <9c72296b0811021528w596e07b4pbd8ed46cdd7ef6c6@mail.gmail.com> Message-ID: <1225879779-sup-7715@existential.local> Excerpts from Chad Scherrer's message of Tue Nov 04 21:34:01 -0600 2008: > Does anyone have any thought what it would take to get this going? > > Chad > Currently, franchise supports building in parallel with a -j flag, but the code could definitely be optimized (in my experience, running with something like -j3 on my dual core reduces compile times with franchise on arbitrary projects about 20% currently.) During the 2008 SOC, there was also work on adding this support to cabal, which eventually ended up as the hbuild project. http://hackage.haskell.org/trac/hackage/wiki/HBuild darcs get http://darcs.net/repos/franchise Austin From schlepptop at henning-thielemann.de Wed Nov 5 06:11:47 2008 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Wed Nov 5 06:03:28 2008 Subject: [Haskell-cafe] Re: Problems with strictness analysis? In-Reply-To: <20081105100202.7156dc52@solaris> References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <1225797501.2283.1282885193@webmail.messagingengine.com> <1225842074.32339.23.camel@derek-laptop> <20081105100202.7156dc52@solaris> Message-ID: <49117F73.9080405@henning-thielemann.de> Achim Schneider schrieb: > Derek Elkins wrote: > >> well-known anti-patterns >> > I'm wondering why there are so miraculously well-known. Could it be the > dedicated wiki page titled "DONTDOTHAT!!!one!" that lists them > all? There was http://www.haskell.org/haskellwiki/Things_to_avoid which has been renamed to the more friendly "Haskell programming tips" From jules at jellybean.co.uk Wed Nov 5 06:18:53 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Nov 5 06:13:47 2008 Subject: [Haskell-cafe] pure programs In-Reply-To: <42784f260811041612i62346327uc8dd5ae919aea43f@mail.gmail.com> References: <42784f260811041612i62346327uc8dd5ae919aea43f@mail.gmail.com> Message-ID: <4911811D.4070105@jellybean.co.uk> Jason Dusek wrote: > Though that seems reasonable, it is not, in general, true. For > example, System.Info.os is generally treated as pure, > though it is not. It's not clear to me how to disambiguate > these "born again" values from really pure values. It seems to me no one addressed your actual point. System.Info is broken. "os" has the wrong type. Sorry about that. There is quite a lot of brokenness in the standard libs which stops pure functions being pure. It's a shame IMO. Jules From neil.mitchell.2 at credit-suisse.com Wed Nov 5 06:24:00 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Wed Nov 5 06:19:19 2008 Subject: [Haskell-cafe] pure programs In-Reply-To: <4911811D.4070105@jellybean.co.uk> References: <42784f260811041612i62346327uc8dd5ae919aea43f@mail.gmail.com> <4911811D.4070105@jellybean.co.uk> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C90396084C@ELON17P32001A.csfb.cs-group.com> > System.Info is broken. "os" has the wrong type. And the wrong value! I have not installed mingw32 on this machine, mingw32 isn't even an os... /me has goal of having "os" on Linux report "wine1.1.7" Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From barsoap at web.de Wed Nov 5 06:33:53 2008 From: barsoap at web.de (Achim Schneider) Date: Wed Nov 5 06:28:53 2008 Subject: [Haskell-cafe] Re: Problems with strictness analysis? References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <1225797501.2283.1282885193@webmail.messagingengine.com> <1225842074.32339.23.camel@derek-laptop> <20081105100202.7156dc52@solaris> <49117F73.9080405@henning-thielemann.de> Message-ID: <20081105123353.013d1dab@solaris> Henning Thielemann wrote: > Achim Schneider schrieb: > > Derek Elkins wrote: > > > >> well-known anti-patterns > >> > > I'm wondering why there are so miraculously well-known. Could it be > > the dedicated wiki page titled "DONTDOTHAT!!!one!" that lists them > > all? > > > There was > http://www.haskell.org/haskellwiki/Things_to_avoid > > which has been renamed to the more friendly > "Haskell programming tips" > I was rather thinking of a list of performance pitfalls and laziness tarpits, starting with the all-famous avg xs = sum xs + length xs The above link seems to consist purely of advice about style and how to avoid imperative thinking, and does not do much to take the fear out of FP and laziness I commonly notice in e.g. C++ programmers: Seeing Haskell, they just don't know what the heck is going on. A list of such things like avg above and stuff like lastInt = last [1..] and explanations on why and how they work (and maybe still don't work) would surely be helpful for people who don't intend or don't even start to consider to read into SPJ's GHC papers. I know that I, coming from a C/Scheme POV, in the beginning attributed much magic to Haskell's inner workings and assumed, because of the general wizardly air of the whole language, avg to run in O(n) time and constant resp. O(n) space. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From lrpalmer at gmail.com Wed Nov 5 06:54:59 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Wed Nov 5 06:49:49 2008 Subject: [Haskell-cafe] Re: Problems with strictness analysis? In-Reply-To: <20081105123353.013d1dab@solaris> References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <1225797501.2283.1282885193@webmail.messagingengine.com> <1225842074.32339.23.camel@derek-laptop> <20081105100202.7156dc52@solaris> <49117F73.9080405@henning-thielemann.de> <20081105123353.013d1dab@solaris> Message-ID: <7ca3f0160811050354s6425a990u1bb5ee87bad23033@mail.gmail.com> On Wed, Nov 5, 2008 at 4:33 AM, Achim Schneider wrote: > I know that I, coming from a C/Scheme POV, in the beginning attributed > much magic to Haskell's inner workings and assumed, because of the > general wizardly air of the whole language, avg to run in O(n) time and > constant resp. O(n) space. Haskell's great strength is its equational semantics. I would like Haskell programmers to think equationally, mathematically, rather than operationally, when writing Haskell programs. If I were to teach a course in Haskell, I would like to launch off of denotational semantics, hopefully without ever having to say "lazy evaluation". (It's a pipe dream, of course, but you get the idea) However, this strength is also a weakness when we want to analyze the efficiency of programs. The denotational semantics of Haskell say nothing about time or space complexity, and give us no tools to reason about it. A Haskell interpreter which randomly rewrites terms until it happens upon a normal form is considered correct (or rather, "correct with probability 1" :-). How can we support analysis of time and space complexity without expanding ourselves into the complicated dirty world of operational thinking? Luke From nicolas.pouillard at gmail.com Wed Nov 5 07:44:37 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Wed Nov 5 07:40:21 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions In-Reply-To: <20081104215903.u428f9np0kcko48w-nwo@webmail.spamcop.net> References: <491080C5.2050706@van.steenbergen.nl> <20081104182606.498e2b28@solaris> <625b74080811041002t5d8a2ec4k342b663af7b6b9d2@mail.gmail.com> <20081104203437.7d4b7327@solaris> <20081104215903.u428f9np0kcko48w-nwo@webmail.spamcop.net> Message-ID: <1225888887-sup-5180@ausone.inria.fr> Excerpts from ajb's message of Wed Nov 05 03:59:03 +0100 2008: > G'day all. Hi, > > Quoting Achim Schneider : > > > Considering that he's talking about a mud, I figure the grammar is a > > quite straightforward > > > > command = l[eft] | r[ight] | ... | t[ake] | c[ast] > > > > That is, I'd be very surprised if you even need more than two or three > > characters lookahead, much less backtracking. > > In the case of a command followed by arguments, it would make more > sense to use a keyword recogniser followed by a command-specific parser. > > One suggestion follows. Oops there is a bug in there: GHCI> keywordMatch [("a", 1), ("aa", 2)] "aa" Nothing The third equation of generateTrie' is missing a guard, namely k1 /= k2. generateTrie' [(k1:ks1,v1),(k2:ks2,v2)] | k1 /= k2 = Node2 k1 (generateTrie [(ks1,v1)]) k2 (generateTrie [(ks2,v2)]) Best regards, -- Nicolas Pouillard aka Ertai From nicolas.pouillard at gmail.com Wed Nov 5 08:10:23 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Wed Nov 5 08:06:04 2008 Subject: [Haskell-cafe] foldl vs foldl' In-Reply-To: <200811050037.47711.daniel.is.fischer@web.de> References: <200811050037.47711.daniel.is.fischer@web.de> Message-ID: <1225890576-sup-8257@ausone.inria.fr> Excerpts from daniel.is.fischer's message of Wed Nov 05 00:37:47 +0100 2008: > Am Mittwoch, 5. November 2008 00:08 schrieb Daryoush Mehrtash: > > Are there cases (function or list) where the result of foldl (or > > foldr)would be different that foldl' (or foldr')? > > > > thanks, > > > > daryoush > > Simple example: > import Data.List > > weird :: Int -> Int -> Int > weird _ 0 = 0 > weird x y = x*y > > list :: [Int] > list = [1, 2, 3, 4, undefined, 6, 7, 8, 9, 0] > > okey = foldl weird 1 list > > boom = foldl' weird 1 list > > *Main> okey > 0 > *Main> boom > *** Exception: Prelude.undefined > > since foldl' evaluates strictly (to WHNF), it can die on encountering an > undefined value in the list where foldl doesn't. Your example is a nice example of foldl over foldl', it would be nice to have it in the wiki page about the different folds[1]. Best regards, [1]: http://haskell.org/haskellwiki/Foldr_Foldl_Foldl%27 -- Nicolas Pouillard aka Ertai From claus.reinke at talk21.com Wed Nov 5 08:24:30 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Nov 5 08:19:56 2008 Subject: [Haskell-cafe] Re: Problems with strictness analysis? References: <1225715493.29387.1282684893@webmail.messagingengine.com><20081103183640.GD22845@scytale.galois.com><20081103213524.GY22845@scytale.galois.com><1225797501.2283.1282885193@webmail.messagingengine.com><1225842074.32339.23.camel@derek-laptop><20081105100202.7156dc52@solaris><49117F73.9080405@henning-thielemann.de><20081105123353.013d1dab@solaris> <7ca3f0160811050354s6425a990u1bb5ee87bad23033@mail.gmail.com> Message-ID: > Haskell's great strength is its equational semantics. I would like > Haskell programmers to think equationally, mathematically, rather than > operationally, when writing Haskell programs. If I were to teach a > course in Haskell, I would like to launch off of denotational > semantics, hopefully without ever having to say "lazy evaluation". > (It's a pipe dream, of course, but you get the idea) > > However, this strength is also a weakness when we want to analyze the > efficiency of programs. The denotational semantics of Haskell say > nothing about time or space complexity, and give us no tools to reason > about it. A Haskell interpreter which randomly rewrites terms until > it happens upon a normal form is considered correct (or rather, > "correct with probability 1" :-). > > How can we support analysis of time and space complexity without > expanding ourselves into the complicated dirty world of operational > thinking? equational /= denotational operational /= bad Sometimes, denotational is too abstract, offering no guidelines on behaviour, just as abstract machine based operational thinking is too concrete, hiding the insights in a flood of details. Sometimes, operational semantics based on directed equations give you the best of both worlds: equational reasoning and behavioural guidelines, both at a suitably "clean" and abstract level. Claus From waldmann at imn.htwk-leipzig.de Wed Nov 5 07:25:25 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Wed Nov 5 08:20:04 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions References: <491080C5.2050706@van.steenbergen.nl> Message-ID: using strings (inside a program) to represent structured data is wrong (*). of course you need strings for interfacing the "outside" world, but the microsecond they get on the inside, they should be tokenized and parsed away into something useful (= an abstract syntax tree). (*) corollary: using strings to represent regular expressions is also wrong... From martijn at van.steenbergen.nl Wed Nov 5 08:56:53 2008 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Wed Nov 5 08:51:44 2008 Subject: [Haskell-cafe] Efficient parallel regular expressions In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C903960843@ELON17P32001A.csfb.cs-group.com> References: <491080C5.2050706@van.steenbergen.nl> <33A3F585590A6F4E81E3D45AA4A111C903960843@ELON17P32001A.csfb.cs-group.com> Message-ID: <4911A625.4060101@van.steenbergen.nl> Hello everyone, Thank you all for your comments! Those are some very useful ideas. I think I'll try roger's (private) and ChrisK's suggestion first: using the match groups. I'm not sure if the match groups inside the individual regexes will cause much trouble, but we'll see. I imagine I'll have to count parentheses, except when it's followed by a \, except when that \ follows another \, etc. There's probably other situations where a () doesn't count as a group, perhaps when it's followed by a * or +. I'll look into that. If that doesn't work out I'll go for Neil's (from an algorithmic POV beautiful) suggestion. While I understand that some of you suggest I use parsec (or some other mature parser library) I'm pretty sure that's not what I want here. The patterns will almost always be very simple and regular expressions offer an extremely concise way of expressing when a hook should fire. Forcing the user to use full parsers would cause the programs to become much more verbose. Still, Yogurt is flexible enough to allow the user to use parsec if he or she so chooses. Thanks again, Martijn. Mitchell, Neil wrote: > Hi Martijn, > > It's not that tricky if you do a regular expression state machine > yourself, but that's probably a bit too much work. One way to get a > speed up might be to take the regular expressions a,b,c,d and > generate a regex a+b+c+d, and one a+b. You can then check any string > s against a+b+c+d, if that matches check a+b, if that matches check > a. At each stage you eliminate half the regular expressions, which > means a match will take log n, where n is the number of regular > expressions. > > This assumes the underlying regular expression engine constructs a > finite state machine, making it O(m) where m is the length of the > string to match. > > Thanks > > Neil From schlepptop at henning-thielemann.de Wed Nov 5 09:04:13 2008 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Wed Nov 5 08:55:56 2008 Subject: [Haskell-cafe] Re: Problems with strictness analysis? In-Reply-To: <20081105123353.013d1dab@solaris> References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <1225797501.2283.1282885193@webmail.messagingengine.com> <1225842074.32339.23.camel@derek-laptop> <20081105100202.7156dc52@solaris> <49117F73.9080405@henning-thielemann.de> <20081105123353.013d1dab@solaris> Message-ID: <4911A7DD.5070406@henning-thielemann.de> Achim Schneider schrieb: > Henning Thielemann wrote: >> >> There was >> http://www.haskell.org/haskellwiki/Things_to_avoid >> >> which has been renamed to the more friendly >> "Haskell programming tips" >> > I was rather thinking of a list of performance pitfalls and laziness > tarpits, starting with the all-famous > > avg xs = sum xs + length xs (/) instead of (+) ? In the old hawiki there was an article about that particular example ... From rogpeppe at gmail.com Wed Nov 5 09:02:05 2008 From: rogpeppe at gmail.com (roger peppe) Date: Wed Nov 5 08:56:57 2008 Subject: [Haskell-cafe] Efficient parallel regular expressions In-Reply-To: References: <491080C5.2050706@van.steenbergen.nl> Message-ID: On Tue, Nov 4, 2008 at 6:44 PM, i wrote: > i'm sorry if this is obviously wrong (i haven't used Text.Regex), but > can't you do this with submatches? rights or wrongs of regexps aside, i just checked that the above approach *is* feasible with Text.Regex here's some code: >module Multimatch(multimatch) where > import Text.Regex > import qualified Data.List as DL > import qualified Data.Maybe as DM > > brcount :: String -> Int > brcount ('\\' : _ : s) = > brcount s > brcount ('(' : s) = > 1 + brcount s > brcount (_ : s) = > brcount s > brcount [] = > 0 > > -- given a list of strings representing regular expressions, > -- each associated with a tag, match against a string > -- and return the match, along with the associated tag, > -- or Nothing if there's no match. > multimatch :: [(tag, String)] -> (String -> Maybe (tag, String)) > multimatch rs = > let re = mkRegex $ DL.intercalate "|" $ map ((\s -> "(x(" ++ s ++ "))") . snd) rs in > let tags = submatches rs in > (\ s -> > do > ms <- matchRegex re ("x" ++ s) > (tag, m) <- DL.find (\(_, m) -> not (null m)) (zip tags ms) > return (DM.fromJust tag, tail m)) > submatches [] = > [] > submatches ((tag, r) : rs) = > (Just tag : take (brcount r + 1) (repeat Nothing)) ++ submatches rs i'm sure there's a more compact implementation in there somewhere: i'm just a haskell newbie. cheers, rog. From rogpeppe at gmail.com Wed Nov 5 09:03:54 2008 From: rogpeppe at gmail.com (roger peppe) Date: Wed Nov 5 08:58:45 2008 Subject: [Haskell-cafe] Efficient parallel regular expressions In-Reply-To: <4911A625.4060101@van.steenbergen.nl> References: <491080C5.2050706@van.steenbergen.nl> <33A3F585590A6F4E81E3D45AA4A111C903960843@ELON17P32001A.csfb.cs-group.com> <4911A625.4060101@van.steenbergen.nl> Message-ID: On Wed, Nov 5, 2008 at 1:56 PM, Martijn van Steenbergen wrote: > I think I'll try roger's (private) eek, bitten by "reply to sender only" again! i had intended to send to the list too. From schlepptop at henning-thielemann.de Wed Nov 5 09:10:49 2008 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Wed Nov 5 09:02:28 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions In-Reply-To: References: <491080C5.2050706@van.steenbergen.nl> Message-ID: <4911A969.3040109@henning-thielemann.de> Johannes Waldmann schrieb: > using strings (inside a program) to represent structured data > is wrong (*). > > of course you need strings for interfacing the "outside" world, > but the microsecond they get on the inside, > they should be tokenized and parsed away > into something useful (= an abstract syntax tree). > > (*) corollary: > using strings to represent regular expressions is also wrong... I consider these regular expression strings an embedded domain-specific language. It seems to me, that putting regexps into strings was a work-around, because you could not extend Haskell's syntax. But now things change with this new GHC feature - what was its name? Nevertheless, I never used regexps in Haskell programs, parsec is much nicer. From barsoap at web.de Wed Nov 5 09:09:33 2008 From: barsoap at web.de (Achim Schneider) Date: Wed Nov 5 09:04:34 2008 Subject: [Haskell-cafe] Re: Problems with strictness analysis? References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <1225797501.2283.1282885193@webmail.messagingengine.com> <1225842074.32339.23.camel@derek-laptop> <20081105100202.7156dc52@solaris> <49117F73.9080405@henning-thielemann.de> <20081105123353.013d1dab@solaris> <7ca3f0160811050354s6425a990u1bb5ee87bad23033@mail.gmail.com> Message-ID: <20081105150933.5fe7fb72@solaris> "Luke Palmer" wrote: > On Wed, Nov 5, 2008 at 4:33 AM, Achim Schneider > wrote: > > I know that I, coming from a C/Scheme POV, in the beginning > > attributed much magic to Haskell's inner workings and assumed, > > because of the general wizardly air of the whole language, avg to > > run in O(n) time and constant resp. O(n) space. > > Haskell's great strength is its equational semantics. I would like > Haskell programmers to think equationally, mathematically, rather than > operationally, when writing Haskell programs. If I were to teach a > course in Haskell, I would like to launch off of denotational > semantics, hopefully without ever having to say "lazy evaluation". > (It's a pipe dream, of course, but you get the idea) > > However, this strength is also a weakness when we want to analyze the > efficiency of programs. The denotational semantics of Haskell say > nothing about time or space complexity, and give us no tools to reason > about it. A Haskell interpreter which randomly rewrites terms until > it happens upon a normal form is considered correct (or rather, > "correct with probability 1" :-). > > How can we support analysis of time and space complexity without > expanding ourselves into the complicated dirty world of operational > thinking? > You can't clean a student's mind from "bad, dirty operational thoughts" by not talking about it as much as you can't exterminate the human race by discontinuing sexual education. Fumbling the keyboard and making things go "blink" and "swoosh" is just too much fun. A natural understanding of what's "clean, elegant and fun" develops over time, and students have to rub their nose into gory and dirty details and code until it bleeds before they see what all that abstract nonsense is good for: Not so much to formalise thinking, but to enable one to speak axiomatically, just like one thinks. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From barsoap at web.de Wed Nov 5 09:12:41 2008 From: barsoap at web.de (Achim Schneider) Date: Wed Nov 5 09:09:56 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions References: <491080C5.2050706@van.steenbergen.nl> <33A3F585590A6F4E81E3D45AA4A111C903960843@ELON17P32001A.csfb.cs-group.com> <4911A625.4060101@van.steenbergen.nl> Message-ID: <20081105151241.1d5fa37f@solaris> "roger peppe" wrote: > On Wed, Nov 5, 2008 at 1:56 PM, Martijn van Steenbergen > wrote: > > I think I'll try roger's (private) > > eek, bitten by "reply to sender only" again! > > i had intended to send to the list too. > I recommend using a newsreader and connecting it to gmane, you won't ever have that problem there. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From barsoap at web.de Wed Nov 5 09:10:49 2008 From: barsoap at web.de (Achim Schneider) Date: Wed Nov 5 09:14:54 2008 Subject: [Haskell-cafe] Re: Problems with strictness analysis? References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <1225797501.2283.1282885193@webmail.messagingengine.com> <1225842074.32339.23.camel@derek-laptop> <20081105100202.7156dc52@solaris> <49117F73.9080405@henning-thielemann.de> <20081105123353.013d1dab@solaris> <4911A7DD.5070406@henning-thielemann.de> Message-ID: <20081105151049.71f258e5@solaris> Henning Thielemann wrote: > Achim Schneider schrieb: > > Henning Thielemann wrote: > >> > >> There was > >> http://www.haskell.org/haskellwiki/Things_to_avoid > >> > >> which has been renamed to the more friendly > >> "Haskell programming tips" > >> > > I was rather thinking of a list of performance pitfalls and laziness > > tarpits, starting with the all-famous > > > > avg xs = sum xs + length xs > > > (/) instead of (+) ? > Only for sufficient correct definitions of avg. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From ketil at malde.org Wed Nov 5 09:31:20 2008 From: ketil at malde.org (Ketil Malde) Date: Wed Nov 5 09:26:11 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: (Tim Newsham's message of "Thu\, 14 Aug 2008 11\:32\:00 -1000 \(HST\)") References: <20080813004714.GN25256@scytale.galois.com> Message-ID: <87ljvymeh3.fsf@malde.org> Old threads never die: Tim Newsham writes: >> Chunk = { >> length :: Word8 >> elems :: [Elem] -- 0..255 repetitions >> } >> Chunks = [Chunk] -- terminated with the first 0 length Chunk > I tried my hand at the encoding above: > > http://www.thenewsh.com/%7Enewsham/store/test10.hs > > it seems to work, although it doesn't seem to be very efficient. > I'm getting very large memory growth when I was hoping it > would be lazy and memory efficient... What's leaking? Did you ever get to the bottom of this? I have a similar problem with Data.Binary that I don't know how to work around yet. It boils down to reading a large list. This exhibits the problem: newtype Foo = Foo [Word8] instance Binary Foo where get = do xs <- replicateM 10000000 get return (Foo xs) Doing 'x <- decodeFile "/dev/zero" and "case x of Foo y -> take 10 y" blows the heap. I thought Data.Binary was lazy? My actual program looks something like this: instance Binary MyData where get = do header <- get data <- replicateM (data_length header) $ do ....stuff to read a data item return (MyData header data) This blows the stack as soon as I try to access anything, even if it's just the contents of the header. Why? My understanding of how Data.Binary works must be sorely lacking. Could some kind soul please disperse some enlightenment in my direction? -k -- If I haven't seen further, it is by standing in the footprints of giants From thomas at cs.ru.nl Wed Nov 5 09:57:06 2008 From: thomas at cs.ru.nl (Thomas van Noort) Date: Wed Nov 5 09:51:57 2008 Subject: [Haskell-cafe] Proposal for associated type synonyms in Template Haskell In-Reply-To: <4b39c80a0811040600y16257eafh5037a851284af10e@mail.gmail.com> References: <49104B62.5010308@cs.ru.nl> <491052AB.2010302@cs.ru.nl> <4b39c80a0811040600y16257eafh5037a851284af10e@mail.gmail.com> Message-ID: <4911B442.7080104@cs.ru.nl> Hello, Recently, we released a library on Hackage for generic rewriting (package "rewriting" if you are curious). The user of the library is expected to define type class instances to enable rewriting on his or her own datatypes. As these instances follow the datatype declarations closely, we tried to generate the instances using Template Haskell. Unfortunately, associated type synonyms are not yet supported by TH. After a presentation at the WGP'08, Simon encouraged us to write a proposal about adding associated type synonyms to TH, so that it can be added to GHC. So, here is our proposal. The TH AST must allow 1) kind declarations of associated type synonyms in class declarations and 2) their definitions in instance declarations. For example, class Foo a where type Bar a :: * instance Foo Int where type Bar Int = String The TH library defines a datatype Dec which contains a constructor for class declarations and instance declarations: data Dec = ... | ClassD Cxt Name [Name] [FunDep] [Dec] | InstanceD Cxt Type [Dec] ... 1) Associated type synonym kind declarations We suggest to add a constructor to the Dec type: ... | AssocTySynKindD Name [Name] (Maybe Kind) ... assocTySynKindD :: Name -> [Name] -> Maybe KindQ -> DecQ The first field is the name of the associated type synonym, the second field is a list of type variables, and the third field is an optional kind. Since kinds are not yet defined in TH, we have to add some kind of kind definition (pun intended): data Kind = StarK | ArrowK Kind Kind type KindQ = Q Kind starK :: KindQ arrowK :: KindQ -> KindQ -> KindQ We explicitly choose not to reuse the Type type to define kinds (i.e., type Kind = Type as in GHC) since we think a separation between the two worlds is much clearer to the users of TH. 2) Associated type synonym definitions We suggest to add another constructor to the Dec type: ... | AssocTySynD Name [Type] Type ... assocTySynD :: Name -> [TypeQ] -> TypeQ -> DecQ The first field is the name of the type synonym, the second field is a list of type arguments, and the third field is the body of the type synonym. We would like to hear your comments to this proposal. Regards, Thomas From ketil at malde.org Wed Nov 5 10:01:07 2008 From: ketil at malde.org (Ketil Malde) Date: Wed Nov 5 09:55:58 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: <87ljvymeh3.fsf@malde.org> (Ketil Malde's message of "Wed\, 05 Nov 2008 15\:31\:20 +0100") References: <20080813004714.GN25256@scytale.galois.com> <87ljvymeh3.fsf@malde.org> Message-ID: <871vxqjjyk.fsf@malde.org> Ketil Malde writes: > Doing 'x <- decodeFile "/dev/zero" Well, it turns out 'decodeFile' needs to -- or does, anyway -- check whether the file is empty. Replacing it with a combination of 'decode' and 'readFile' solved the problem. Thanks to Saizan and the other people hanging around on #haskell. -k -- If I haven't seen further, it is by standing in the footprints of giants From kr.angelov at gmail.com Wed Nov 5 10:17:37 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Wed Nov 5 10:12:28 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: Message-ID: I had the same problem (stack overflow). The solution was to change the >>= operator in the Get monad. Currently it is: m >>= k = Get (\s -> let (a, s') = unGet m s in unGet (k a) s') but I changed it to: m >>= k = Get (\s -> case unGet m s of (a, s') -> unGet (k a) s') It seems that the bind operator is lazy and this caused the stack overflow. I have also another problem. Every Int and Word is stored as 64-bit value and this expands the output file a lot. I have a lot of integers and most of them are < 128 but not all of them. I changed the serialization so that the Int and Word are serialized in a variable number of bytes. Without this change the binary serialization was even worse than the textual serialization that we had before. The file was almost full with zeros. I just haven't time to prepare a patch and to send it for review but if other people have the same problem I will do it. Best Regars, Krasimir On Wed, Aug 13, 2008 at 1:13 AM, Tim Newsham wrote: > I have a program that read in and populated a large data structure and > then saved it out with Data.Binary and Data.ByteString.Lazy.Char8: > > saveState db = B.writeFile stateFile =<< > encode <$> atomically (readTVar db) > > when I go to read this in later I get a stack overflow: > > loadState db = do > d <- decode <$> B.readFile stateFile > atomically $ writeTVar db d > > Stack space overflow: current size 8388608 bytes. > Use `+RTS -Ksize' to increase it. > > or from ghci: > > d <- liftM decode > (Data.ByteString.Lazy.Char8.readFile > "savedState.bin") :: IO InstrsDb > > fromList *** Exception: stack overflow > > The data type I'm storing is a Map (of maps): > > type DailyDb = M.Map Date Daily > type InstrsDb = M.Map String DailyDb > > What's going on here? Why is the system capable of building and saving > the data but not in reading and umarhsalling it? What is the proper way > to track down where the exception is happening? Any debugging tips? > > I also noticed another issue while testing. If my program loads > the data at startup by calling loadState then all later calls to > saveState give an error: > > Log: savedState.bin: openFile: resource busy (file is locked) > > this does not occur if the program wasnt loaded. My best guess here > is that B.readFile isnt completing and closing the file for some > reason. Is there a good way to force this? > > Tim Newsham > http://www.thenewsh.com/~newsham/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From kr.angelov at gmail.com Wed Nov 5 10:20:52 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Wed Nov 5 10:25:44 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: <20080813001820.GH25256@scytale.galois.com> References: <20080813001820.GH25256@scytale.galois.com> Message-ID: On Wed, Aug 13, 2008 at 1:18 AM, Don Stewart wrote: > instance Binary a => Binary [a] where > put l = put (length l) >> mapM_ put l > get = do n <- get :: Get Int > replicateM n get Of course I changed this as well. Now it is: instance (Ord k, Binary k, Binary e) => Binary (Map.Map k e) where put m = put (Map.size m) >> mapM_ put (Map.toAscList m) get = liftM Map.fromDistinctAscList get You don't have to convert the map to list just to compute its size. The Map.size is a O(1) function. From alexanderforemny at googlemail.com Wed Nov 5 10:34:23 2008 From: alexanderforemny at googlemail.com (Alexander Foremny) Date: Wed Nov 5 10:29:13 2008 Subject: [Haskell-cafe] Writing an IRC bot, problems with plugins Message-ID: Hello, Community. I already bothered #haskell a few times with the very same problem and always got interesting responses. But I seem to have always simplified my problem too much ending up with an helpful answer to my (simplified) problem, but not with a real solution. Thus I'm giving the mailing list a try where I don't feel like having to wrap up my concerns in as few lines as possible. I am writing an single server, multi channel IRC bot with the support of plugins and limited plugin communication. With the plugin system I am facing problems I cannot really solve myself. My general idea is to have the main application listening to the network socket and then calling all the plugins on each incoming message. Therefore I maintain a list of plugin states in the main application's state and on each incoming message I call a function which modifies the plugin's state. There's a PluginClass class which contains definitions of functions for each plugin which they all share. Simplyfied it's like this: type PL = StateT PluginConfig class PluginClass a where identifier :: a -> String rawMessage :: (MonadIO m) => a -> Message -> PL m () So plugins can be identified uniquely using the identifier function and they can respond to messages using the rawMessage function. This function is executed in the PL monad, which is essentially a StateT monad for updating the plugin's state trough put and maybe accessing a few data fields from the underlying Bot monad in which the main application is operating. Then again I want to be able to query a plugin's state from a different plugin. For instance I'll have a plugin which keeps track of the channels the bot has joined collecting user information, the topic, etc. Another plugin could then query the "chan info" plugin and get all the users in a certain channel through a queryPlugin function which takes a plugin and looks that plugin up in the main application's plugin state list for the right state and then calls a function on it. The plugin and the corresponding functions would be exported by the plugin's module. queryPlugin :: (PluginClass a) => a -> (a -> b) -> PL m b queryPlugin pl f = do plugins <- getGlobalPlugins -- ideally (PluginClass a) => [a] let pluginNames = map identifier plugins targetName = identifier pl [(_, target)] = filter ((==) targetName . fst) (zip pluginNames plugin) return (f target) But here I am facing either one or the other problem, depending on the "solution." 1) I somehow have to store all the plugin states in the main application. Since plugins are essentially their states, they are quite arbitrary. I either cannot use a list for that or I have to use existential types which would make that possible. 2) Using an existential plugin type would restrict the functions I am able to call on the plugin to those which are supported by the PluginClass. This would render queryPlugin unusable since the functions a plugin exports for query the state are arbitrary. 3) I could use Dynamics to store the plugin in a list *and* call arbitrary functions, but then again how would I run a plugin? All the main application know about the plugin state is that all the functions defined by PluginClass are callable on the state. But the type (PluginClass a) => a isn't enough to unwrap the Dynamic, apply the function and wrap it again. Another suggestion was to not use a class but make each plugin a record, exporting the functions itself. Though I haven't given that a serious thought, it seems not ideal to me. Using a class a plugin can define the functions it actually uses. In my real code, they're about 12 functions the class exports and there could be more. Using a record I would have to implement all possible functions even though they're not changing the plugin's state nor causing side effects. The most obvious solution would be to use an algebraic data type with a constructor for each plugin. But I'd like to develop the plugins independent from the core and I'd like to make them more dynamic than that, maybe implementing dynamic loading of plugins at some time. Then there are two other potential solutions, but I haven't looked into them seriously since they seemed a little hackish to me at first glance. One would be using Hlist (which seems to be over-sized for my problem as well) and another would be to store a tupel of (Dynamic, (PluginClass a) => (Dynamic -> a)) as plugin state list where the first element would be the plugin's state wrapped in a dynamic and the second a unwrap function exported by the plugin's module. I *might* get around the problem of being to unspecific about the type when unwrapping, but this idea came only at the point of writing this email and I would expect running into the same problems I have: It can be achieved by either being too general or being to specific. Hopefully I've explained everything well enough while not being too long with all this. Thanks in advance for your help! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081105/80a66112/attachment.htm From jefferson.r.heard at gmail.com Wed Nov 5 11:54:30 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Wed Nov 5 11:49:21 2008 Subject: [Haskell-cafe] HOpenGL wiki link to documentation is broken Message-ID: <4165d3a70811050854o5b63315atb6c03b48668636a0@mail.gmail.com> I suspect this has to do with the latest GHC not including it by default, but the HOpenGL wiki's documentation links are broken. -- Jeff From dmehrtash at gmail.com Wed Nov 5 13:01:12 2008 From: dmehrtash at gmail.com (Daryoush Mehrtash) Date: Wed Nov 5 12:57:32 2008 Subject: [Haskell-cafe] foldl vs foldl' In-Reply-To: <200811050037.47711.daniel.is.fischer@web.de> References: <200811050037.47711.daniel.is.fischer@web.de> Message-ID: Lets assume we don't have undefined in the list, are there functions (or properties in the function) that would cause foldl to have different results than foldl'? daryoush On Tue, Nov 4, 2008 at 3:37 PM, Daniel Fischer wrote: > Am Mittwoch, 5. November 2008 00:08 schrieb Daryoush Mehrtash: > > Are there cases (function or list) where the result of foldl (or > > foldr)would be different that foldl' (or foldr')? > > > > thanks, > > > > daryoush > > Simple example: > import Data.List > > weird :: Int -> Int -> Int > weird _ 0 = 0 > weird x y = x*y > > list :: [Int] > list = [1, 2, 3, 4, undefined, 6, 7, 8, 9, 0] > > okey = foldl weird 1 list > > boom = foldl' weird 1 list > > *Main> okey > 0 > *Main> boom > *** Exception: Prelude.undefined > > since foldl' evaluates strictly (to WHNF), it can die on encountering an > undefined value in the list where foldl doesn't. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081105/239150b4/attachment.htm From jonathanccast at fastmail.fm Wed Nov 5 13:06:32 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Nov 5 13:00:58 2008 Subject: [Haskell-cafe] foldl vs foldl' In-Reply-To: References: <200811050037.47711.daniel.is.fischer@web.de> Message-ID: <1225908392.13332.15.camel@jcchost> On Wed, 2008-11-05 at 10:01 -0800, Daryoush Mehrtash wrote: > Lets assume we don't have undefined in the list, are there functions > (or properties in the function) that would cause foldl to have > different results than foldl'? If the function is partial on some elements of the list. (3 /), for example, if the list contains 0. If f is total over the elements of the list (whether the elements of the list are partial or total) and f z /= _|_, then foldl' f z = foldl f z. jcc From dons at galois.com Wed Nov 5 14:10:01 2008 From: dons at galois.com (Don Stewart) Date: Wed Nov 5 14:04:33 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: Message-ID: <20081105191001.GA321@scytale.galois.com> kr.angelov: > I had the same problem (stack overflow). The solution was to change > the >>= operator in the Get monad. Currently it is: > > m >>= k = Get (\s -> let (a, s') = unGet m s > in unGet (k a) s') > > but I changed it to: > > m >>= k = Get (\s -> case unGet m s of > (a, s') -> unGet (k a) s') > > It seems that the bind operator is lazy and this caused the stack overflow. Hmm. That's interesting. I'm not sure that doesn't change other things we rely on though. > I have also another problem. Every Int and Word is stored as 64-bit > value and this expands the output file a lot. I have a lot of integers > and most of them are < 128 but not all of them. I changed the > serialization so that the Int and Word are serialized in a variable > number of bytes. Without this change the binary serialization was even > worse than the textual serialization that we had before. The file was > almost full with zeros. The motivation for this is to use zlib compress / decompress. E.g. writeFile "f" . compress . encode $ foo > I just haven't time to prepare a patch and to send it for review but > if other people have the same problem I will do it. > Patches welcome. You shouldn't need to patch a library like this, it should be able to do what you need. -- Don From dons at galois.com Wed Nov 5 14:10:32 2008 From: dons at galois.com (Don Stewart) Date: Wed Nov 5 14:05:02 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813001820.GH25256@scytale.galois.com> Message-ID: <20081105191032.GB321@scytale.galois.com> kr.angelov: > On Wed, Aug 13, 2008 at 1:18 AM, Don Stewart wrote: > > instance Binary a => Binary [a] where > > put l = put (length l) >> mapM_ put l > > get = do n <- get :: Get Int > > replicateM n get > > Of course I changed this as well. Now it is: > > instance (Ord k, Binary k, Binary e) => Binary (Map.Map k e) where > put m = put (Map.size m) >> mapM_ put (Map.toAscList m) > get = liftM Map.fromDistinctAscList get > > You don't have to convert the map to list just to compute its size. > The Map.size is a O(1) function. If you have a more efficient instance Binary Map, please send a patch. Collaborate! -- Don From jason.dusek at gmail.com Wed Nov 5 14:20:49 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed Nov 5 14:15:40 2008 Subject: [Haskell-cafe] pure programs In-Reply-To: <4911811D.4070105@jellybean.co.uk> References: <42784f260811041612i62346327uc8dd5ae919aea43f@mail.gmail.com> <4911811D.4070105@jellybean.co.uk> Message-ID: <42784f260811051120j850ae9djd4171080b6046e78@mail.gmail.com> Jules Bean wrote: > Jason Dusek wrote: > > Though that seems reasonable, it is not, in general, true. > > For example, System.Info.os is generally treated as > > pure, though it is not. It's not clear to me how to > > disambiguate these "born again" values from really pure > > values. > > System.Info is broken. "os" has the wrong type. > > Sorry about that. There is quite a lot of brokenness in the > standard libs which stops pure functions being pure. It's a > shame IMO. I've thought about this a little bit, and it may be okay. What if our rule for program purity is a program, once compiled, may be moved from environment to environment, and will either execute consistently or simply fail to execute. Consider this program: import System.Info main = putStrLn os If I compile it on Linux and then run the executable on FreeBSD, it will either fail to run, because FreeBSD Linux compatibility got worse since I tried it last, or run and print linux as it would on Linux. Does this seem reasonable? As long as the programs are statically linked, through and through, they should be pure. Admittedly, this approach does not address "source level purity", which is impossible due to `unsafePerformIO` and, more generally, conditional compilation. -- _jsn From goofyheadedpunk at gmail.com Wed Nov 5 14:45:24 2008 From: goofyheadedpunk at gmail.com (Brian Troutwine) Date: Wed Nov 5 14:40:14 2008 Subject: [Haskell-cafe] Strictness problems with Control.Event? Message-ID: <971980cc0811051145p523b3547tc15a79d6c4585085@mail.gmail.com> I'm attempting to use Control.Event to limit HTTP requests made by a dippy little scraper I'm constructing to once per second but I think, maybe, that the Events are not being evaluated. First, some imports. > import qualified Data.ByteString as B > import qualified Data.ByteString.Char8 as C > import Network.Curl.Download > import Network.Curl.Opts > import System.Exit > import System.Environment > import System.Time > import Control.Event > import Control.Monad > import Data.Char The Event function of this program is append. It takes a local path and a URL, retrieves the contents pointed to by the URL and appends them to the local path. The function download, below, performs the retrieval. > append :: FilePath -> C.ByteString -> IO () > append f u = > B.appendFile f . addNew . C.filter (not . isAscii) =<< download u > where addNew = C.append (C.pack "\n") > download :: B.ByteString -> IO B.ByteString > download url = do > res <- openURIWithOpts [CurlEncoding "gzip", CurlUserAgent "aule-0.0.2"] $ C.unpack url > case res of > Left _ -> exitFailure > Right cont -> B.putStrLn cont >> return cont The function sched adds a list of Events to the evtSys system, a fixed time delay between each. > sched :: EventSystem -> ClockTime -> Integer -> Integer -> (t -> IO ()) -> [t] -> IO () > sched _ _ _ _ _ [] = return () > sched evtSys (TOD sec _) delay mul action (x:xs) = do > addEvent evtSys (TOD (sec + (delay*mul)) 0) (action x) > sched evtSys (TOD sec 0) delay (mul + 1) action xs main is, as usual, pretty boring. The program compiles and runs, but no output file is made. This being one of my first appreciable Haskell programs, I rather imagine I've run into a strictness problem, maybe. Would someone be so kind as to steer me in the right direction? > main :: IO () > main = do > [i, o] <- getArgs > eS <- initEventSystem > t <- getClockTime > inp <- B.readFile i > sched eS t 1 1 (append o) (C.lines inp) Thanks, Brian From dumashkurko at gmail.com Wed Nov 5 14:46:20 2008 From: dumashkurko at gmail.com (dmitry shkurko) Date: Wed Nov 5 14:41:10 2008 Subject: [Haskell-cafe] Undefined symbols base_DataziTuple_ZxxxT_con_info Message-ID: <3425cc630811051146g16ab0c2fo882113bce700fc89@mail.gmail.com> Hello everyone, I am trying to compile my program, but during the linking phase I see errors like: (.text+0x66dd7):fake: undefined reference to `base_DataziTuple_Z110T_con_info Library libHSbase.a contains symbols base_DataziTuple_ZxxxT_con_info for xxx <=62. It look like I hit some compiler limit (I used GHC 6.8.3 for compilation). Any thoughts are appreciated. Thank you, Dmitry From bulat.ziganshin at gmail.com Wed Nov 5 15:01:55 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Nov 5 14:57:21 2008 Subject: [Haskell-cafe] Undefined symbols base_DataziTuple_ZxxxT_con_info In-Reply-To: <3425cc630811051146g16ab0c2fo882113bce700fc89@mail.gmail.com> References: <3425cc630811051146g16ab0c2fo882113bce700fc89@mail.gmail.com> Message-ID: <1225601940.20081105230155@gmail.com> Hello dmitry, Wednesday, November 5, 2008, 10:46:20 PM, you wrote: > (.text+0x66dd7):fake: undefined reference to `base_DataziTuple_Z110T_con_info looks like you omitted --make on cmdline. without this switch, ghc don't automaticaly links in packages used in you program. alternatively you may try to use "--package base" (for this case) but --make is more generic way - it automatically links in all packages used -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Wed Nov 5 15:26:23 2008 From: dons at galois.com (Don Stewart) Date: Wed Nov 5 15:20:57 2008 Subject: [Haskell-cafe] Writing an IRC bot, problems with plugins In-Reply-To: References: Message-ID: <20081105202623.GD390@scytale.galois.com> alexanderforemny: > My general idea is to have the main application listening to the network > socket and then calling all the plugins on each incoming message. > Therefore I maintain a list of plugin states in the main application's > state and on each incoming message I call a function which modifies the > plugin's state. Like lambdabot! > There's a PluginClass class which contains definitions of functions for > each plugin which they all share. Simplyfied it's like this: > > type PL = StateT PluginConfig > > class PluginClass a where > identifier :: a -> String > rawMessage :: (MonadIO m) => a -> Message -> PL m () Like lambdabot, kind of. > So plugins can be identified uniquely using the identifier function and > they can respond to messages using the rawMessage function. This function > is executed in the PL monad, which is essentially a StateT monad for > updating the plugin's state trough put and maybe accessing a few data > fields from the underlying Bot monad in which the main application is > operating. > > Then again I want to be able to query a plugin's state from a different > plugin. For instance I'll have a plugin which keeps track of the channels > the bot has joined collecting user information, the topic, etc. Another > plugin could then query the "chan info" plugin and get all the users in a > certain channel through a queryPlugin function which takes a plugin and > looks that plugin up in the main application's plugin state list for the > right state and then calls a function on it. The plugin and the > corresponding functions would be exported by the plugin's module. > > queryPlugin :: (PluginClass a) => a -> (a -> b) -> PL m b > queryPlugin pl f = do > plugins <- getGlobalPlugins -- ideally (PluginClass a) => [a] > let pluginNames = map identifier plugins > targetName = identifier pl > [(_, target)] = filter ((==) targetName . fst) (zip pluginNames > plugin) > return (f target) > > But here I am facing either one or the other problem, depending on the > "solution." > > 1) I somehow have to store all the plugin states in the main application. > Since plugins are essentially their states, they are quite arbitrary. I > either cannot use a list for that or I have to use existential types which > would make that possible. Existential types are used in lambdabot for this. I'd probably use an associated type to connect the plugin to its state type now, too. > 2) Using an existential plugin type would restrict the functions I am able > to call on the plugin to those which are supported by the PluginClass. > This would render queryPlugin unusable since the functions a plugin > exports for query the state are arbitrary. You might be able to design around this. Lambdabot manages ok with existentially typed interfaces. -- Don From cgibbard at gmail.com Wed Nov 5 16:15:53 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Wed Nov 5 16:10:42 2008 Subject: [Haskell-cafe] view patterns In-Reply-To: <1ff5dedc0811042134x3e5c3f67ld12408c54037a629@mail.gmail.com> References: <1ff5dedc0811042134x3e5c3f67ld12408c54037a629@mail.gmail.com> Message-ID: <89ca3d1f0811051315q27fed7edwf6433eba3c64b089@mail.gmail.com> 2008/11/5 Cetin Sert : > :1:4: > Warning: Pattern match(es) are overlapped > In the definition of `emp': > emp ((has -> True)) = ... > emp ((has -> False)) = ... > > Why do I get this error in ghc or when I try to compile a file with view > patterns? > (using -fglasgow-exts and -XViewPatterns, ghc 6.10.1) This is a bug which appears to be known about: http://hackage.haskell.org/trac/ghc/ticket/2395 - Cale From derek.a.elkins at gmail.com Wed Nov 5 17:48:49 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Wed Nov 5 17:43:43 2008 Subject: [Haskell-cafe] foldl vs foldl' In-Reply-To: References: <200811050037.47711.daniel.is.fischer@web.de> Message-ID: <1225925329.32339.26.camel@derek-laptop> On Wed, 2008-11-05 at 10:01 -0800, Daryoush Mehrtash wrote: > Lets assume we don't have undefined in the list, are there functions > (or properties in the function) that would cause foldl to have > different results than foldl'? The only difference in the definition of foldl and foldl' is a seq so it can only differ due to bottoms as far as semantics is concerned. From ok at cs.otago.ac.nz Wed Nov 5 18:14:44 2008 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Wed Nov 5 18:09:35 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions In-Reply-To: References: <491080C5.2050706@van.steenbergen.nl> Message-ID: <9DBA0DB2-315C-405D-A8CC-87DAEC7D4F6E@cs.otago.ac.nz> On 6 Nov 2008, at 1:25 am, Johannes Waldmann wrote: > using strings (inside a program) to represent structured data > is wrong (*). +1 From david.waern at gmail.com Wed Nov 5 18:21:00 2008 From: david.waern at gmail.com (David Waern) Date: Wed Nov 5 18:15:50 2008 Subject: [Haskell-cafe] ANNOUNCE: Haddock version 2.4.0 Message-ID: -------------------------------------------- -- Haddock 2.4.0 -------------------------------------------- A new version of Haddock, the Haskell documentation tool, is out. This is a later version than the one shipped with GHC 6.10.1, which is version 2.3.0. That version will not be released on Hackage since it only builds with GHC 6.10.1 (by accident, actually). Besides adding back support for earlier GHC versions, this release contains some more fixes and support for HTML frames. Please use the bug tracker to submit bug reports or feature requests. -------------------------------------------- -- Changes in version 2.4.0 -------------------------------------------- * Add framed view of the HTML documentation * Build with GHC 6.8.2 and 6.8.3 again * Support images in documentation comments again * Small improvements to the Hoogle output * A few bugs has been fixed -------------------------------------------- -- Changes in version 2.3.0 -------------------------------------------- * Support for GHC 6.10.1 * Slightly improved space usage * Fix a bug that made hidden modules show up in the contents & index pages * Fix a bug that made Haddock load modules twice * Improvements to the Hoogle output -------------------------------------------- -- Links -------------------------------------------- Homepage: http://www.haskell.org/haddock Hackage page: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.4.0 Bugtracker and wiki: http://trac.haskell.org/haddock Mailing list: haskelldoc@haskell.org Code repository: http://code.haskell.org/haddock -------------------------------------------- -- Contributors -------------------------------------------- The persons who contributed to the 2.3.0 and 2.4.0 releases are: Clemens Fruhwirth Peter Gavin Ian Lynagh Neil Mitchell Luke Plant Thomas Schilling David Waern -------------------------------------------- -- Get Involved -------------------------------------------- We welcome new contributors. To get involved, start by grabbing the code: http://code.haskell.org/haddock Then take a look at the bug and feature tracker for things to work on: http://trac.haskell.org/haddock From lrpalmer at gmail.com Wed Nov 5 18:34:36 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Wed Nov 5 18:29:26 2008 Subject: [Haskell-cafe] Re: Problems with strictness analysis? In-Reply-To: References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103213524.GY22845@scytale.galois.com> <1225797501.2283.1282885193@webmail.messagingengine.com> <1225842074.32339.23.camel@derek-laptop> <20081105100202.7156dc52@solaris> <49117F73.9080405@henning-thielemann.de> <20081105123353.013d1dab@solaris> <7ca3f0160811050354s6425a990u1bb5ee87bad23033@mail.gmail.com> Message-ID: <7ca3f0160811051534q1b3d76f8kf8f75b2c84ae487e@mail.gmail.com> On Wed, Nov 5, 2008 at 1:24 AM, Claus Reinke wrote: >> How can we support analysis of time and space complexity without >> expanding ourselves into the complicated dirty world of operational >> thinking? > > equational /= denotational Nonetheless, Haskell has equational semantics which are derived from its denotational ones. But when I said "equational semantics" I really meant something more like "equations" :-). > operational /= bad > > Sometimes, denotational is too abstract, offering no guidelines on > behaviour, just as abstract machine based operational thinking is too > concrete, hiding > the insights in a flood of details. Sometimes, operational semantics based > on directed equations give you the best of both worlds: equational reasoning > and behavioural guidelines, both at a suitably "clean" and abstract level. By directed equations you mean unidirectional rewrite rules? But I'd like to back up a bit. I may have been too quick to assign the judgement "dirty" to operational thinking. I am not asking this question as a complaint, as a challenge on the language, or as any other such rhetorical device: my question is earnest. I would like to know or to develop a way to allow abstract analysis of time and space complexity. On my time working with Haskell, I've developed a pretty accurate "intuition" about the performance of programs. It is some meld of thinking in terms of the lazy evaluation mechanism, some higher-level rules of thumb about when new thunks are allocated, and probably some other stuff hiding in the depths of my brain. I know it, but I am not satisfied with it, because I can't formalize it. I wouldn't be able to write them down and explain to a fellow mathematician how I reason about Haskell programs. The example being discussed in this thread is a good one: sum [1..10^8] + length [1..10^8] With Haskell's semantics, we know we can write this as: let xs = [1..10^8] in sum xs + length xs But it causes a change in memory *complexity*, so in some sense these two sentences are not equal. What is the theory in which we can observe this fact? Is it possible to give a simple denotational semantics which captures it? From bulat.ziganshin at gmail.com Wed Nov 5 18:53:34 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Nov 5 18:48:57 2008 Subject: [Haskell-cafe] Re: Problems with strictness analysis? In-Reply-To: <7ca3f0160811051534q1b3d76f8kf8f75b2c84ae487e@mail.gmail.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103213524.GY22845@scytale.galois.com> <1225797501.2283.1282885193@webmail.messagingengine.com> <1225842074.32339.23.camel@derek-laptop> <20081105100202.7156dc52@solaris> <49117F73.9080405@henning-thielemann.de> <20081105123353.013d1dab@solaris> <7ca3f0160811050354s6425a990u1bb5ee87bad23033@mail.gmail.com> <7ca3f0160811051534q1b3d76f8kf8f75b2c84ae487e@mail.gmail.com> Message-ID: <101380140.20081106025334@gmail.com> Hello Luke, Thursday, November 6, 2008, 2:34:36 AM, you wrote: > The example being discussed in this thread is a good one: > sum [1..10^8] + length [1..10^8] > With Haskell's semantics, we know we can write this as: > let xs = [1..10^8] in sum xs + length xs > But it causes a change in memory *complexity*, so in some sense these > two sentences are not equal. What is the theory in which we can > observe this fact? Is it possible to give a simple denotational > semantics which captures it? i'm not a mathematician, but why you can't explore term rewriting system? it has some graph at initial stage and modifies it until normal form is reached. graphs representing first and second expression are different (first is tree while second have two two links to [1..10^8] node) and this oes to difference between their evaluation process. on the every step of rewriting of first graph itssize remains O(1), while second graph during rewriting grows up to O(n) size -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From claus.reinke at talk21.com Wed Nov 5 19:25:49 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Nov 5 19:20:42 2008 Subject: [Haskell-cafe] Re: Problems with strictness analysis? References: <1225715493.29387.1282684893@webmail.messagingengine.com><20081103213524.GY22845@scytale.galois.com><1225797501.2283.1282885193@webmail.messagingengine.com><1225842074.32339.23.camel@derek-laptop><20081105100202.7156dc52@solaris><49117F73.9080405@henning-thielemann.de><20081105123353.013d1dab@solaris><7ca3f0160811050354s6425a990u1bb5ee87bad23033@mail.gmail.com> <7ca3f0160811051534q1b3d76f8kf8f75b2c84ae487e@mail.gmail.com> Message-ID: <9EA4FAA8DE214CB68FD84ADBA0B1BC8A@cr3lt> >> equational /= denotational > > Nonetheless, Haskell has equational semantics which are derived from > its denotational ones. But when I said "equational semantics" I > really meant something more like "equations" :-). Unlike Standard ML, for instance, Haskell does not have standard semantics - a persistent embarrassment. There are semantics for fragments, but no guarantee that any of them will match any part of the language, let alone its implementations. One can base equational semantics on denotational semantics, but that is not the only way, hence the two are not equal. I was trying to point out the missing part, where equations are are useful for operational reasoning, beyond simple denotations. >> Sometimes, operational semantics based >> on directed equations give you the best of both worlds: equational reasoning >> and behavioural guidelines, both at a suitably "clean" and abstract level. > > By directed equations you mean unidirectional rewrite rules? Yes. Think of rewriting (replacing old with new) as a general form of operational semantics.Within this form, there is a wide range of possibilities, including rewriting abstract machine states and rewriting source-level programs. Somewhere near the latter, there is a "most abstract" form of operational semantics for a language, one for which every other form adds details that are not inherent in the language, but are artifacts of the formalisation (details of the abstract machine, or details of the mathematical domain, or ..). > But I'd like to back up a bit. I may have been too quick to assign > the judgement "dirty" to operational thinking. I am not asking this > question as a complaint, as a challenge on the language, or as any > other such rhetorical device: my question is earnest. I would like to > know or to develop a way to allow abstract analysis of time and space > complexity. So you want to reason about the way from the original program to its outputs, not just about the outputs. You can cling to denotations, by extending mere values with information about the computation leading to those values, but why not reason about the computation directly. In logic terms, you want to talk about the proof, not just about the truth of your theorems. In functional language terms, you want to talk about reductions, not just about normal forms. This works well for pure lambda calculus, and has been extended to cover other aspects of Haskell implementations, such as call-by-need lambda calculus as a way for evaluation of non-strict programs with sharing. The call-by-need lambda calculus John Maraist and Martin Odersky and Philip Wadler Journal of Functional Programming, 1998 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.44.5259 The idea is to use "let" to represent sharing, and to refine the reduction rules to take this into account: instead of substituting parameters into function bodies, parameter bindings are kept in "let"-bindings, where their evaluation is shared (only values can be substituted, so substitution is preceded by evaluation, when needed). The resulting reductions are quite a bit more involved than without sharing, because all reductions take place within a context (those "let"-bindings). But that is quite close to what happens in a compiled graph reduction implementation: those "let"-bindings represent the heap, the nested contexts correspond to stack. (there are of course optimizations and representation changes that affect performance, but the former are themselves expressed as rewrite rules, and the latter can be accounted for by refining the rewrite system, when such details are needed - luckily, that isn't often the case) > On my time working with Haskell, I've developed a pretty accurate > "intuition" about the performance of programs. It is some meld of > thinking in terms of the lazy evaluation mechanism, some higher-level > rules of thumb about when new thunks are allocated, and probably some > other stuff hiding in the depths of my brain. I know it, but I am not > satisfied with it, because I can't formalize it. I wouldn't be able > to write them down and explain to a fellow mathematician how I reason > about Haskell programs. > > The example being discussed in this thread is a good one: > > sum [1..10^8] + length [1..10^8] > > With Haskell's semantics, we know we can write this as: > > let xs = [1..10^8] in sum xs + length xs > > But it causes a change in memory *complexity*, so in some sense these > two sentences are not equal. What is the theory in which we can > observe this fact? Is it possible to give a simple denotational > semantics which captures it? Why do you insist on denotational semantics for reasoning about evaluation? Denotational semantics are best when all you care about are values. Have a look at that paper, or the earlier version http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.39.2287 There is also John Launchbury, A Natural Semantics for Lazy Evaluation,1993 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.35.2016 which used an explicit heap to capture sharing (the later use of "let" made it possible to talk about sharing without adding any constructs not in the language). Either of these, if extended with the necessary primitives, should distinguish your two terms: in the former, sharing of the long list never arises (so the computations are independent), in the latter, that sharing is never lost (so evaluating one sub-term will evaluate the shared xs, which are kept around until the other sub-term gets to consuming them) . Claus From conal at conal.net Wed Nov 5 20:01:42 2008 From: conal at conal.net (Conal Elliott) Date: Wed Nov 5 19:56:31 2008 Subject: [Haskell-cafe] pure programs In-Reply-To: <42784f260811041612i62346327uc8dd5ae919aea43f@mail.gmail.com> References: <42784f260811041612i62346327uc8dd5ae919aea43f@mail.gmail.com> Message-ID: Hi Jason, To help me understand your question, would you be unhappy with the following structure? -- runnable main = interact f -- composable f = ... The discipline is to use interact (or another combinator) to wrap a functional/composable/pure component like f into an executable. Then give main to users and f to programmers. This same game can be made more sophisticated, eg main = interact (show . f . read) Or unparse & parse in place of show & read. For more on combining usability and composability, see http://haskell.org/haskellwiki/TV http://conal.net/blog/posts/tangible-functional-programming-a-modern-marriage-of-usability-and-composability/ - Conal On Tue, Nov 4, 2008 at 4:12 PM, Jason Dusek wrote: > Informally, a "pure program" an executable such that the > stream of bytes entering it totally determines the stream of > bytes leaving it. > > Many useful programs that I would like to write in Haskell > don't fall into this category -- for example, network servers > -- but a lot of their components do. Can these components can > be Haskell functions without IO in their signatures? > > Though that seems reasonable, it is not, in general, true. For > example, System.Info.os is generally treated as pure, > though it is not. It's not clear to me how to disambiguate > these "born again" values from really pure values. > > -- > _jsn > _______________________________________________ > 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/20081105/5aec6dd3/attachment.htm From a.biurvOir4 at asuhan.com Thu Nov 6 00:53:10 2008 From: a.biurvOir4 at asuhan.com (Kim-Ee Yeoh) Date: Thu Nov 6 00:47:58 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: <7ca3f0160811051534q1b3d76f8kf8f75b2c84ae487e@mail.gmail.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103183640.GD22845@scytale.galois.com> <20081103213524.GY22845@scytale.galois.com> <1225797501.2283.1282885193@webmail.messagingengine.com> <1225842074.32339.23.camel@derek-laptop> <20081105100202.7156dc52@solaris> <49117F73.9080405@henning-thielemann.de> <20081105123353.013d1dab@solaris> <7ca3f0160811050354s6425a990u1bb5ee87bad23033@mail.gmail.com> <7ca3f0160811051534q1b3d76f8kf8f75b2c84ae487e@mail.gmail.com> Message-ID: <20355554.post@talk.nabble.com> Luke Palmer-2 wrote: > > I would like to know or to develop a way to allow abstract > analysis of time and space complexity. > In the same way that type inference and strictness analysis can be seen as instances of abstract interpretation, so can complexity inference. I agree that the interplay between these various instances of AI is an unexplored lode for us cogheads. Below are 2 references to complexity inference. I have yet to look closely to ascertain the degree of compositionality of their methodologies. Can anyone recommend a survey paper of the entire field? Linear, Polynomial or Exponential? Complexity Inference in Polynomial Time Amir M. Ben-Amram, Neil D. Jones and Lars Kristiansen http://dx.doi.org/10.1017/S0956796800003865 Automated complexity analysis of Nuprl extracted programs Ralph Benzinger http://dx.doi.org/10.1007/978-3-540-69407-6_7 -- View this message in context: http://www.nabble.com/Problems-with-strictness-analysis--tp20301967p20355554.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From wren at freegeek.org Thu Nov 6 01:57:15 2008 From: wren at freegeek.org (wren ng thornton) Date: Thu Nov 6 01:52:04 2008 Subject: [Haskell-cafe] Re: Problems with strictness analysis? In-Reply-To: <7ca3f0160811051534q1b3d76f8kf8f75b2c84ae487e@mail.gmail.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> <20081103213524.GY22845@scytale.galois.com> <1225797501.2283.1282885193@webmail.messagingengine.com> <1225842074.32339.23.camel@derek-laptop> <20081105100202.7156dc52@solaris> <49117F73.9080405@henning-thielemann.de> <20081105123353.013d1dab@solaris> <7ca3f0160811050354s6425a990u1bb5ee87bad23033@mail.gmail.com> <7ca3f0160811051534q1b3d76f8kf8f75b2c84ae487e@mail.gmail.com> Message-ID: <4912954B.80003@freegeek.org> Luke Palmer wrote: > The example being discussed in this thread is a good one: > > sum [1..10^8] + length [1..10^8] > > With Haskell's semantics, we know we can write this as: > > let xs = [1..10^8] in sum xs + length xs > > But it causes a change in memory *complexity*, so in some sense these > two sentences are not equal. What is the theory in which we can > observe this fact? Is it possible to give a simple denotational > semantics which captures it? There's actually been a good deal of work on trying to mathematize this sort of issue, under the name of linear logic[1]. The problem with classical equational reasoning is that it doesn't capture the notion of "resources" or the "sharing" thereof. The two expressions are not the same because the first has two [1..10^8] resources it can use up, whereas the later only has one. Depending on the balance between sharing temporal work vs minimizing memory overhead, sometimes it's okay to add sharing and other times it's okay to remove it, but in general both options are not available at once. It's pretty easy to capture issues of economy with LL, though making a rewriting system takes a bit more framework. I'm not sure to what extent LL has been explored as a semantic model for programs, but Clean[2] and Phil Wadler[3] have certainly done very similar work. [1] [2] [3] -- Live well, ~wren From barsoap at web.de Thu Nov 6 03:15:56 2008 From: barsoap at web.de (Achim Schneider) Date: Thu Nov 6 03:11:00 2008 Subject: [Haskell-cafe] Re: foldl vs foldl' References: <200811050037.47711.daniel.is.fischer@web.de> <1225925329.32339.26.camel@derek-laptop> Message-ID: <20081106091556.5436e37e@solaris> Derek Elkins wrote: > On Wed, 2008-11-05 at 10:01 -0800, Daryoush Mehrtash wrote: > > Lets assume we don't have undefined in the list, are there functions > > (or properties in the function) that would cause foldl to have > > different results than foldl'? > > The only difference in the definition of foldl and foldl' is a seq so > it can only differ due to bottoms as far as semantics is concerned. > Denotational semantics that is, isn't it? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From wren at freegeek.org Thu Nov 6 03:28:23 2008 From: wren at freegeek.org (wren ng thornton) Date: Thu Nov 6 03:23:12 2008 Subject: [Haskell-cafe] Re: Problems with strictness analysis? In-Reply-To: References: <1225715493.29387.1282684893@webmail.messagingengine.com> <490F993F.8080109@freegeek.org> Message-ID: <4912AAA7.3080207@freegeek.org> Dominic Steinitz wrote: > wren ng thornton freegeek.org> writes: > > [snick] > > > > isum 0 s = s > > > isum n s = isum (n-1) (s+n) > > This is tail recursive, and will be optimized to an iterative loop; > > [snick] > > > In terms of having a compiler 'smart enough', it's not clear that > > functions of this sort ought to be inferred strict simply because the > > accumulator is ultimately returned to the caller. Consider for example: > > I thought this was strict as Luke Palmer has already pointed out. My > understanding is that a compiler may be able to infer it is strict and then > perform eager evaluation. But how should a compiler infer that it's strict? That's the trick. It's easy enough to come up with examples that would foil any naive attempt at inference ---like the (++) and (.) examples--- and it's not entirely clear that a general solution is possible. GHC's strictness analyzer will capture many things, but it's conservative enough to ensure that it doesn't change the semantics of the program. Strictness annotations are about declaring the semantics of the program, so any optimizations done by the compiler must ensure that they don't change the strictness properties of the original program.[1] Even for this particular example, it's not clear that making isum strict in the accumulator is correct. The issue here is that isum does not have a type annotation and so it's polymorphic in (+). For the Int and Integer instances it happens that (+) is strict, but we could also have a Num instance for Peano integers or some other lazy representation, and this function should work on them as well--- preserving the least-strictness of the (+) operator for those types. For strict (+) it's true that isum n _|_ == _|_, but for any (+) that's lazy in its first argument that's not true. S(S(S _|_)) is a perfectly valid Peano integer and forbidding it as a return value from this function would alter the semantics from what was written in the definition. If Haskell had strictness annotations as part of the type system, then there might be room for progress. We could imagine constructing separate polymorphic bodies for isum, one for each strictness variant of (+). Then, when isum is instantiated at types which define strict (+) we could use an optimized version of isum that forces evaluation at each step. Now the trick becomes how to control the explosion of generated code for all the combinatorially many strictness variants of types. For whole-program optimizing compilers, it should be relatively easy to keep the code bloat down, but for separate compilation it's not so straightforward. Chances are that any solution along this route would still require strictness annotations in order to do the right thing, only now we've lifted the annotations into the type language instead of leaving them in the term language. > > > f 0 xs = xs > > > f n xs = f (n-1) (replicate n n ++ xs) > > > > Since (++) can indeed return partial answers, it's fine for the > > accumulator to be lazy. Indeed, making it strict harms performance > > significantly. Another example is when the accumulator is a function, as > > Can this function be strict if (++)isn't? And if it isn't strict, why would it > make sense to evaluate it eagerly? Depends what you mean by "strict". Adding ($!) before the accumulator will force each (++) thunk to WHNF, which will in turn force the replicate thunk to WHNF. Additional annotations could make the entire spine strict, or all the elements strict as well. Everything *can* be made strict, whether it ought to be is a separate matter entirely. The point was that a simple heuristic like detecting accumulator patterns and making the accumulators strict is not always a good idea. Adding that ($!) to the function will double the evaluation time and makes no semantic difference. It *doesn't* make sense to evaluate the accumulator eagerly, because you'll still have a bunch of thunks, they're just pushed back one element in the list. The only way for strictness to alter the semantics of this particular function is if the entire spine of the second argument is forced (which in turn makes it take time quadratic in the length of the return value, not to mention the extra space for the whole list). > PS This subject seems to come up often enough to be worth a wiki entry (maybe > there already is one). I think we should also be careful with terminology (as > Luke Palmer and David Menendez have pointed out. Maybe that could be included > in the wiki entry. It would be worth a wiki. In addition to the strict/non-strict vs eager/lazy distinction, it's also important to distinguish unlifted types from unboxed types (which both come up in this sort of discussion). [1] So for example, optimizations like those in are not the sorts of things which it would be correct for a compiler to perform automatically. Importing that module can dramatically change the strictness properties of a program. Generally this is for the best since it simply eliminates excessive computation, but if anyone is relying on the strictness properties of the length function, it breaks those properties and so it may break their program. -- Live well, ~wren From wren at freegeek.org Thu Nov 6 03:48:13 2008 From: wren at freegeek.org (wren ng thornton) Date: Thu Nov 6 03:43:01 2008 Subject: [Haskell-cafe] Efficient parallel regular expressions In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C903960843@ELON17P32001A.csfb.cs-group.com> References: <491080C5.2050706@van.steenbergen.nl> <33A3F585590A6F4E81E3D45AA4A111C903960843@ELON17P32001A.csfb.cs-group.com> Message-ID: <4912AF4D.40705@freegeek.org> Mitchell, Neil wrote: > Hi Martijn, > > It's not that tricky if you do a regular expression state machine > yourself, but that's probably a bit too much work. One way to get > a speed up might be to take the regular expressions a,b,c,d and > generate a regex a+b+c+d, and one a+b. You can then check any string > s against a+b+c+d, if that matches check a+b, if that matches check > a. At each stage you eliminate half the regular expressions, which > means a match will take log n, where n is the number of regular > expressions. > > This assumes the underlying regular expression engine constructs a > finite state machine, making it O(m) where m is the length of the > string to match. If you're implementing the machine yourself, you can implement it as trie automaton which has some "value" associated with each final state. That is, rather than just accepting or rejecting, when the automaton accepts it returns the value associated with the particular final state that it accepted by. This is a trivial extension on DFA/NFA implementations and is perfectly suited to the problem of combining multiple linear tries (sic: regexes) into a single machine. The minimization algorithms are a bit more complex than for DFA/NFAs, but still fairly straightforward if you're only doing prefix merging. And this gets rid of the O(log n) factor. -- Live well, ~wren From wren at freegeek.org Thu Nov 6 04:00:22 2008 From: wren at freegeek.org (wren ng thornton) Date: Thu Nov 6 03:55:11 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions In-Reply-To: <4910AC48.60607@list.mightyreason.com> References: <491080C5.2050706@van.steenbergen.nl> <4910AC48.60607@list.mightyreason.com> Message-ID: <4912B226.9070605@freegeek.org> ChrisK wrote: > If you need to be left-biased then you need a perl-style engine, and you > can use the regex-pcre or pcre-light haskell package and the PCRE > library. These are obtainable from Hackage. I doubt PCRE uses a simple > DFA... I don't know if regex-pcre or pcre-light supports the (?{...})-ism of Perl 5.6 and above, but if it does then it's fairly easy to implement the trie automaton I mentioned in my previous post: just add a (?{ $value = ... }) action to the end of each component regex and read out the value of $value after you match. You'll still want to run the automata through a minimizer/optimizer after gluing all the components together, otherwise you still get O(n) behavior since you don't share the work for common prefixes. -- Live well, ~wren From bulat.ziganshin at gmail.com Thu Nov 6 04:05:20 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Nov 6 04:00:43 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions In-Reply-To: <4912B226.9070605@freegeek.org> References: <491080C5.2050706@van.steenbergen.nl> <4910AC48.60607@list.mightyreason.com> <4912B226.9070605@freegeek.org> Message-ID: <1656085391.20081106120520@gmail.com> Hello wren, Thursday, November 6, 2008, 12:00:22 PM, you wrote: > the trie automaton I mentioned in my previous post: just add a (?{ > $value = ... }) action to the end of each component regex and read out > the value of $value after you match. $value? in haskell? :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From wren at freegeek.org Thu Nov 6 04:17:51 2008 From: wren at freegeek.org (wren ng thornton) Date: Thu Nov 6 04:12:40 2008 Subject: [Haskell-cafe] Re: Efficient parallel regular expressions In-Reply-To: <1656085391.20081106120520@gmail.com> References: <491080C5.2050706@van.steenbergen.nl> <4910AC48.60607@list.mightyreason.com> <4912B226.9070605@freegeek.org> <1656085391.20081106120520@gmail.com> Message-ID: <4912B63F.3080906@freegeek.org> Bulat Ziganshin wrote: > Hello wren, > > Thursday, November 6, 2008, 12:00:22 PM, you wrote: > >> the trie automaton I mentioned in my previous post: just add a (?{ >> $value = ... }) action to the end of each component regex and read out >> the value of $value after you match. > > $value? in haskell? :) Shh, they'll notice :) -- "callCC implementation left as an exercise for the reader" ~wren From duncan.coutts at worc.ox.ac.uk Thu Nov 6 04:40:33 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 6 04:35:23 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: Haddock version 2.4.0 In-Reply-To: References: Message-ID: <1225964433.8437.317.camel@localhost> On Thu, 2008-11-06 at 00:21 +0100, David Waern wrote: > -------------------------------------------- > -- Haddock 2.4.0 > -------------------------------------------- > > A new version of Haddock, the Haskell documentation tool, is out. > > This is a later version than the one shipped with GHC 6.10.1, which is version > 2.3.0. That version will not be released on Hackage since it only builds with > GHC 6.10.1 (by accident, actually). Will .haddock files generated by haddock-2.3.0 work with haddock-2.4? If not it would be preferable to have a 2.3.1 release or something for distributions that want to package haddock separately from ghc (eg gentoo). Otherwise we somehow have to hack the ghc build procedure to use an external haddock (that we'd have previously compiled using the same ghc version). Duncan From dumashkurko at gmail.com Thu Nov 6 04:46:23 2008 From: dumashkurko at gmail.com (dmitry shkurko) Date: Thu Nov 6 04:41:10 2008 Subject: [Haskell-cafe] Undefined symbols base_DataziTuple_ZxxxT_con_info In-Reply-To: <1225601940.20081105230155@gmail.com> References: <3425cc630811051146g16ab0c2fo882113bce700fc89@mail.gmail.com> <1225601940.20081105230155@gmail.com> Message-ID: <3425cc630811060146y177c22d1h4580570300d029a2@mail.gmail.com> Hello Bulat, Thanks for suggestion. The problem is not reproducible w/ GHC 6.10.1. Regards, Dmitry On Thu, Nov 6, 2008 at 2:01 AM, Bulat Ziganshin wrote: > Hello dmitry, > > Wednesday, November 5, 2008, 10:46:20 PM, you wrote: > >> (.text+0x66dd7):fake: undefined reference to `base_DataziTuple_Z110T_con_info > > looks like you omitted --make on cmdline. without this switch, ghc > don't automaticaly links in packages used in you program. > alternatively you may try to use "--package base" (for this case) but > --make is more generic way - it automatically links in all packages > used > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > From david.waern at gmail.com Thu Nov 6 04:46:41 2008 From: david.waern at gmail.com (David Waern) Date: Thu Nov 6 04:41:28 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: Haddock version 2.4.0 In-Reply-To: <1225964433.8437.317.camel@localhost> References: <1225964433.8437.317.camel@localhost> Message-ID: 2008/11/6 Duncan Coutts : > Will .haddock files generated by haddock-2.3.0 work with haddock-2.4? If > not it would be preferable to have a 2.3.1 release or something for > distributions that want to package haddock separately from ghc (eg > gentoo). Otherwise we somehow have to hack the ghc build procedure to > use an external haddock (that we'd have previously compiled using the > same ghc version). They will. The .haddock file format has not changed between these versions. David From lennart at augustsson.net Thu Nov 6 05:02:25 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Nov 6 04:57:13 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: <1225715493.29387.1282684893@webmail.messagingengine.com> References: <1225715493.29387.1282684893@webmail.messagingengine.com> Message-ID: I tried your example in GHC 6.10 and isum appears to work fine. The type of 10000000 gets defaulted to Integer, a specialized version of isum for Integer is then created, the strictness analyzer determines that isum is strict in s, and the code generator produces a loop. (If you want to look at the assembly code, it's easier if you make the type Int.) Ghc 6.8 had a bug (if I remember right) so when defaulting was involved it didn't always optimize things properly. -- Lennart On Mon, Nov 3, 2008 at 12:31 PM, Patai Gergely wrote: > Hi everyone, > > I was experimenting with simple accumulator functions, and found that an > apparently tail recursive function can easily fill the stack. Playing > around with ghc and jhc gave consistently unpleasant results. Look at > this program: > > %%%%%%%%%%% > > -- ghc: no, ghc -O3: yes, jhc: no > isum 0 s = s > isum n s = isum (n-1) (s+n) > > -- ghc: no, ghc -O3: no, jhc: yes (because gcc -O3 is clever) > rsum 0 = 0 > rsum n = n + rsum (n-1) > > main = case isum 10000000 0 {- rsum 10000000 -} of > 0 -> print 0 > x -> print x > > %%%%%%%%%%% > > I would expect the analysis to find out that the result of the function > is needed in every case (since we are matching a pattern to it), yet I > need to add a $! to the recursive call of isum to get a truly iterative > function. It's interesting how ghc and jhc seem to diverge, one > favouring the "iterative" version, the other the "recursive" one > (although it only works because gcc figures out that the function can be > expressed in an iterative way). > > Of course this is a real problem when I'm trying to write an actual > program, since it means I can be bitten by the laziness bug any time... > Is there any solution besides adding strictness annotations? Can I > expect the compiler to handle this situation better in the foreseeable > future? > > Gergely > > -- > http://www.fastmail.fm - IMAP accessible web-mail > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From barsoap at web.de Thu Nov 6 06:24:03 2008 From: barsoap at web.de (Achim Schneider) Date: Thu Nov 6 06:19:02 2008 Subject: [Haskell-cafe] Re: Problems with strictness analysis? References: <1225715493.29387.1282684893@webmail.messagingengine.com> <490F993F.8080109@freegeek.org> <4912AAA7.3080207@freegeek.org> Message-ID: <20081106122403.5ec722be@solaris> wren ng thornton wrote: > If Haskell had strictness annotations as part of the type system, > then there might be room for progress. We could imagine constructing > separate polymorphic bodies for isum, one for each strictness variant > of (+). Then, when isum is instantiated at types which define strict > (+) we could use an optimized version of isum that forces evaluation > at each step. Now the trick becomes how to control the explosion of > generated code for all the combinatorially many strictness variants > of types. For whole-program optimizing compilers, it should be > relatively easy to keep the code bloat down, but for separate > compilation it's not so straightforward. Chances are that any > solution along this route would still require strictness annotations > in order to do the right thing, only now we've lifted the annotations > into the type language instead of leaving them in the term language. > Code explosion is actually what we want, as things like (+) are best if unboxed and inlined, to one of the thousands of machine instructions the target architecture offers for that operation (think x86, amd64, x87, mmx, sse, sse2...). As a side note, you made me think about y-combinators, stream fusion and lists of computations that can be rewritten to use the minimum number of y's possible/computable. It appears to have a lot in common with strictness/eagerness if you eg. think of [n..] as a fixpoint of the form y (\num_calls -> num_calls + n). FP semanticists will now cry "Heresy! Repeat after me: Pure is pure and impure is impure, always and ever", so I rather shut up and think before I make even less sense. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From briqueabraque at yahoo.com Thu Nov 6 06:30:00 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Thu Nov 6 06:25:00 2008 Subject: [Haskell-cafe] Monad.Reader with updates Message-ID: Hi, Is there some abstraction in current ghc library that implements something like Reader, but where the value of the environment is updated at every "step"? I imagine something that instead of running like this: runReader ( do ... ) environment I would run like: runReader ( do ... ) environment update_function So, when I write a monad like: do a <- asks f b <- asks f2 c <- asks f3 f, f2 and f3 would be called with parameters environment, (update_function environment), (update_function . updatefunction $ environment) etc. Does that make sense? Is it easy to adapt something already existing to do that? Thanks, Maur?cio From bulat.ziganshin at gmail.com Thu Nov 6 06:46:12 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Nov 6 06:41:40 2008 Subject: [Haskell-cafe] Monad.Reader with updates In-Reply-To: References: Message-ID: <971065662.20081106144612@gmail.com> Hello Mauricio, Thursday, November 6, 2008, 2:30:00 PM, you wrote: > Is there some abstraction in current ghc library > that implements something like Reader, but where > the value of the environment is updated at every > "step"? do-it-yourself? you can start from reader definition and add what you need. you just need to make "initial state" consisting from state itself and update function so `run` will have just one initialization argument -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From briqueabraque at yahoo.com Thu Nov 6 06:52:16 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Thu Nov 6 06:47:20 2008 Subject: [Haskell-cafe] Re: Monad.Reader with updates In-Reply-To: <971065662.20081106144612@gmail.com> References: <971065662.20081106144612@gmail.com> Message-ID: >> Is there some abstraction in current ghc library >> that implements something like Reader, but where >> the value of the environment is updated at every >> "step"? > > do-it-yourself? you can start from reader definition and add what you > need. you just need to make "initial state" consisting from state > itself and update function so `run` will have just one initialization argument > Sure. I've done a few versions, trying to change the way (>>=) is defined, and learned a lot with that. But I wanted to know if there's already the "right way to do it" instead of my "newbie way to do it" :) Thanks, Maur?cio From bulat.ziganshin at gmail.com Thu Nov 6 07:16:08 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Nov 6 07:11:37 2008 Subject: [Haskell-cafe] Re: Monad.Reader with updates In-Reply-To: References: <971065662.20081106144612@gmail.com> Message-ID: <12210102295.20081106151608@gmail.com> Hello Mauricio, Thursday, November 6, 2008, 2:52:16 PM, you wrote: > that. But I wanted to know if there's already the > "right way to do it" instead of my "newbie way to > do it" :) "All about monads" doesn't mention it, at least :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jules at jellybean.co.uk Thu Nov 6 07:40:25 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Thu Nov 6 07:35:15 2008 Subject: [Haskell-cafe] Re: Monad.Reader with updates In-Reply-To: References: <971065662.20081106144612@gmail.com> Message-ID: <4912E5B9.1010204@jellybean.co.uk> Mauricio wrote: >>> Is there some abstraction in current ghc library >>> that implements something like Reader, but where >>> the value of the environment is updated at every >>> "step"? >> >> do-it-yourself? you can start from reader definition and add what you >> need. you just need to make "initial state" consisting from state >> itself and update function so `run` will have just one initialization >> argument >> > > Sure. I've done a few versions, trying to change > the way (>>=) is defined, and learned a lot with > that. But I wanted to know if there's already the > "right way to do it" instead of my "newbie way to > do it" :) It doesn't quite make sense, because one "step" isn't well defined. How many "steps" is "return (f x)" ? how about "return x >>= \y -> return (f y)" ? Because the monad laws guarantee those two things should be the same, and yet the first is zero steps and the second is one step, going by the crude "counting >>=s" method I'm guess you were thinking of. So I think you'd have to make the steps explicit. You could do this with a custom version of (>>) and (>>=) which automatically do a step, for example. So advance :: m () -- your primitive which changes the environment a >>* b = a >> advance >> b a >>*= f = do { r <- a; advance; f r } Does that help? Jules From briqueabraque at yahoo.com Thu Nov 6 07:59:59 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Thu Nov 6 07:55:08 2008 Subject: [Haskell-cafe] http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-Simple.html Message-ID: Hi, According to this page: http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-Simple.html there's an available toplevel declaration named: autoconfUserHooks in Distribution.Simple. However: ghci --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 ghci Prelude> :m +Distribution.Simple Prelude Distribution.Simple> :t autoconfUserHooks :1:0: Not in scope: `autoconfUserHooks' What would the experienced Haskell programmer do in such situation? Is there some way to ask ghci (or ghc) to list all available declarations, in a way that I could '| grep' it or save it to a file? Can I ask ghci to look for a declaration inside all available modules in all available packages? Thanks, Maur?cio From gwern0 at gmail.com Thu Nov 6 08:41:23 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Thu Nov 6 08:36:09 2008 Subject: [Haskell-cafe] http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-Simple.html In-Reply-To: References: Message-ID: On Thu, Nov 6, 2008 at 7:59 AM, Mauricio wrote: > Hi, > > According to this page: > > http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-Simple.html > > there's an available toplevel declaration named: > > autoconfUserHooks > > in Distribution.Simple. However: > > ghci --version > The Glorious Glasgow Haskell Compilation System, version 6.8.2 > > ghci > Prelude> :m +Distribution.Simple > Prelude Distribution.Simple> :t autoconfUserHooks > :1:0: Not in scope: `autoconfUserHooks' > > What would the experienced Haskell programmer do in such > situation? Is there some way to ask ghci (or ghc) to list > all available declarations, in a way that I could '| grep' > it or save it to a file? Can I ask ghci to look for a > declaration inside all available modules in all available > packages? > > > Thanks, > Maur?cio You can try the :browse command. -- gwern From Malcolm.Wallace at cs.york.ac.uk Thu Nov 6 08:41:13 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Nov 6 08:38:51 2008 Subject: [Haskell-cafe] Haskell Quick Reference (1-page PDF) Message-ID: <20081106134113.114c0ef3.Malcolm.Wallace@cs.york.ac.uk> Some time ago, there was a thread about a "CheatSheet" for Haskell beginners. As I recall, the CheatSheet was more than 12 pages long. For a Haskell tutorial I was running at a conference recently, I needed a "Quick Reference Guide" that would fit onto a single side of A4. So I knocked one together quickly, and it is attached as a PDF. I send it to this list, with permission for anyone to distribute it more widely as they wish, in the hope that it might be useful. Doubtless it is incomplete, and I have no particular desire to fix errors or maintain this document, so if anyone is interested and would like to adopt it, I can pass on the editable sources. It was originally created as an Apple Numbers spreadsheet (simply for speed of creation) but could be converted to Excel or CSV, for import into other tools. Regards, Malcolm -------------- next part -------------- A non-text attachment was scrubbed... Name: QuickReference.pdf Type: application/pdf Size: 75561 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081106/ed21f119/QuickReference-0001.pdf From briqueabraque at yahoo.com Thu Nov 6 09:18:42 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Thu Nov 6 09:13:47 2008 Subject: [Haskell-cafe] Re: Monad.Reader with updates In-Reply-To: <4912E5B9.1010204@jellybean.co.uk> References: <971065662.20081106144612@gmail.com> <4912E5B9.1010204@jellybean.co.uk> Message-ID: >>>> Is there some abstraction in current ghc library that implements >>>> something like Reader, but where the value of the environment is >>>> updated at every "step"? >>> > It doesn't quite make sense, because one "step" isn't well defined. > How many "steps" is "return (f x)" ? how about "return x >>= \y -> > return (f y)" ? (...) > I understand. But do you think something like the (obviously not working) code below could respect monad laws, if I could consider (environment->a) a monad over a? update = snd . next ; -- this updates a random number generator instance RandomGen environment => Monad ( environment -> a ) where { -- below, f :: g1 -> ( environment -> g2 ) p >>= f = p2 where { p2 e = ( f . p $ e ) . update } ; return = const ; } Then I would do something like: getStdGen >>= ( return . do { a >>= b >>= c } ) > > So I think you'd have to make the steps explicit. (...) > > advance :: m () -- your primitive which changes the environment > > a >>* b = a >> advance >> b > a >>*= f = do { r <- a; advance; f r } > The problem is that I need 'a' or 'b' above to sometimes also change the environment. I think with this method I could not get that. Thanks, Maur?cio From barsoap at web.de Thu Nov 6 09:39:42 2008 From: barsoap at web.de (Achim Schneider) Date: Thu Nov 6 09:34:37 2008 Subject: [Haskell-cafe] Re: Monad.Reader with updates References: <971065662.20081106144612@gmail.com> <4912E5B9.1010204@jellybean.co.uk> Message-ID: <20081106153942.7a1462ae@solaris> Mauricio wrote: > [...] > Are you sure you don't want to use monad transformers? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From mail at joachim-breitner.de Thu Nov 6 10:48:16 2008 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu Nov 6 10:43:04 2008 Subject: [Haskell-cafe] Haskell Quick Reference (1-page PDF) In-Reply-To: <20081106134113.114c0ef3.Malcolm.Wallace@cs.york.ac.uk> References: <20081106134113.114c0ef3.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <1225986496.3455.24.camel@otto.ehbuehl.net> Hi, the reference suggests the use of otherwise (instead of _) as the default pattern in a case expression. While it certainly works, isn?t it bad style, as it shadows Prelude.otherwise: $ cat otherwise.lhs ; runhaskell otherwise.lhs >demo b arg = case b of > True -> do print "First arg was True" > let g | arg == "Something" = print "Got something" > | otherwise = print "Got anything else" > g > otherwise -> do print "First arg was not True" > let g | arg == "Something" = print "Got something" > | otherwise = print "Got anything else" > g > >main = do demo True "Something" > demo True "Something else" > demo False "Something" > demo False "Something else" "First arg was True" "Got something" "First arg was True" "Got anything else" "First arg was not True" "Got something" "First arg was not True" otherwise.lhs: otherwise.lhs:(7,36)-(8,86): Non-exhaustive patterns in function g I know that this is a contrieved example (using case on a boolean), but in other cases you?ll get strange type errors. So while I think I did it in the past, otherwise should be avoided in case expressions. Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081106/47028612/attachment.bin From briqueabraque at yahoo.com Thu Nov 6 11:46:48 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Thu Nov 6 11:41:46 2008 Subject: [Haskell-cafe] Re: http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-Simple.html In-Reply-To: References: Message-ID: >> According to this page: >> >> http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-Simple.html >> >> there's an available toplevel declaration named: >> >> autoconfUserHooks >> >> in Distribution.Simple. However: >> >> ghci --version >> The Glorious Glasgow Haskell Compilation System, version 6.8.2 >> >> ghci >> Prelude> :m +Distribution.Simple >> Prelude Distribution.Simple> :t autoconfUserHooks >> :1:0: Not in scope: `autoconfUserHooks' >> >> (...) > > You can try the :browse command. > But I understand that :browse only shows already loaded modules, or a given list of modules. The whole point is that the declaration I'm looking for is not anywhere I can find it (except in the documentation). From briqueabraque at yahoo.com Thu Nov 6 11:48:12 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Thu Nov 6 11:44:51 2008 Subject: [Haskell-cafe] Re: Monad.Reader with updates In-Reply-To: <20081106153942.7a1462ae@solaris> References: <971065662.20081106144612@gmail.com> <4912E5B9.1010204@jellybean.co.uk> <20081106153942.7a1462ae@solaris> Message-ID: > >> [...] >> > Are you sure you don't want to use monad transformers? > No. Do you have a sugestion on how could I do it in this situation? Maur?cio From rmm-haskell at z.odi.ac Thu Nov 6 11:51:29 2008 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Thu Nov 6 11:46:11 2008 Subject: [Haskell-cafe] Re: http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-Simple.html In-Reply-To: References: Message-ID: <49132091.3070301@z.odi.ac> The docs in latest are for 6.10.1 at this point, I don't think that function is in 6.8.2: http://www.haskell.org/ghc/docs/6.8.2/html/libraries/Cabal/Distribution-Simple.html -Ross Maur??cio wrote: >>> According to this page: >>> >>> http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-Simple.html >>> >>> >>> there's an available toplevel declaration named: >>> >>> autoconfUserHooks >>> >>> in Distribution.Simple. However: >>> >>> ghci --version >>> The Glorious Glasgow Haskell Compilation System, version 6.8.2 >>> >>> ghci >>> Prelude> :m +Distribution.Simple >>> Prelude Distribution.Simple> :t autoconfUserHooks >>> :1:0: Not in scope: `autoconfUserHooks' >>> > >> (...) > >> >> You can try the :browse command. >> > > But I understand that :browse only shows already > loaded modules, or a given list of modules. The > whole point is that the declaration I'm looking > for is not anywhere I can find it (except in the > documentation). > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From jules at jellybean.co.uk Thu Nov 6 12:21:44 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Thu Nov 6 12:16:33 2008 Subject: [Haskell-cafe] Re: Monad.Reader with updates In-Reply-To: References: <971065662.20081106144612@gmail.com> <4912E5B9.1010204@jellybean.co.uk> Message-ID: <491327A8.80408@jellybean.co.uk> Mauricio wrote: > The problem is that I need 'a' or 'b' above to sometimes also change the > environment. I think with this method I could not get that. I no longer understand what you want. I thought you wanted an environment which automatically changed every "step". I showed you how you can do that, although it requires making explicit what a "step" is, which you could do with custom combinators. Now you want any part of the action to change the environment? In this case, use the state monad, not the reader monad. That is what it's for. Jules From david.waern at gmail.com Thu Nov 6 13:35:34 2008 From: david.waern at gmail.com (David Waern) Date: Thu Nov 6 13:30:21 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: Haddock version 2.4.0 In-Reply-To: <200811061559.10325.g9ks157k@acme.softbase.org> References: <200811061559.10325.g9ks157k@acme.softbase.org> Message-ID: 2008/11/6 Wolfgang Jeltsch : > Am Donnerstag, 6. November 2008 00:21 schrieb David Waern: >> * Add framed view of the HTML documentation > > After many years with many people telling us that frames are bad, you add > frame support to Haddock? Hmm. You should discuss this with Simon Marlow, as it was his idea. Thomas Schilling implemented it. Personally, I think the frames are quite handy, although not that pretty in their current form. More importantly, you don't need to use them if you don't want to. Haddock still generates the normal index.html as well as frames.html. David From ryani.spam at gmail.com Thu Nov 6 14:04:34 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Nov 6 13:59:24 2008 Subject: [Haskell-cafe] Re: Monad.Reader with updates In-Reply-To: References: <971065662.20081106144612@gmail.com> <4912E5B9.1010204@jellybean.co.uk> Message-ID: <2f9b2d30811061104m12257cb6pc6d4fdcb74544819@mail.gmail.com> Hi Mauricio. What you want actually already exists in QuickCheck as the "Gen" monad. >From http://hackage.haskell.org/packages/archive/QuickCheck/1.1.0.0/doc/html/src/Test-QuickCheck.html#Gen newtype Gen a = Gen (Int -> StdGen -> a) instance Monad Gen where return a = Gen (\n r -> a) Gen m >>= k = Gen (\n r0 -> let (r1,r2) = split r0 Gen m' = k (m n r1) in m' n r2) This has an additional "size" parameter in the environment, but other than that it sounds like exactly what you are asking for. There is the problem, as others have pointed out, that it doesn't strictly follow the monad laws; (m >>= return) is not the same as (m). You can make a "fast and loose" argument that the whole point is that each view of the generator is supposed to get a random source, so the fact that it is a different random source shouldn't matter. I'm not sure how one would go about a formal analysis of this property. But it doesn't seem to have caused any problems for the QuickCheck folks. You could also implement this as a variation on the State monad if you wanted to avoid using split: import Control.Monad.State advance :: RNG -> RNG -- supplied by you newtype GenA a = GenA (State RNG a) runGenA (GenA m) = m instance Monad GenA where return a = GenA $ return a m >>= k = GenA $ do a <- runGenA m modify advance runGenA (k a) (The obvious extension to StateT applies to make GenAT). -- ryan On Thu, Nov 6, 2008 at 6:18 AM, Mauricio wrote: >>>>> Is there some abstraction in current ghc library that implements >>>>> something like Reader, but where the value of the environment is >>>>> updated at every "step"? >>>> >> It doesn't quite make sense, because one "step" isn't well defined. >> How many "steps" is "return (f x)" ? how about "return x >>= \y -> >> return (f y)" ? (...) >> > > I understand. But do you think something like the (obviously not > working) code below could respect monad laws, if I could consider > (environment->a) a monad over a? > > update = snd . next ; -- this updates a random number generator > > instance RandomGen environment => Monad ( environment -> a ) where { > > -- below, f :: g1 -> ( environment -> g2 ) > p >>= f = p2 where { p2 e = ( f . p $ e ) . update } ; > > return = const ; > > } > > Then I would do something like: > > getStdGen >>= ( return . do { a >>= b >>= c } ) > >> >> So I think you'd have to make the steps explicit. (...) >> >> advance :: m () -- your primitive which changes the environment >> >> a >>* b = a >> advance >> b >> a >>*= f = do { r <- a; advance; f r } >> > > The problem is that I need 'a' or 'b' above to sometimes also change the > environment. I think with this method I could not get that. > > Thanks, > Maur?cio > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From camior at gmail.com Thu Nov 6 16:14:49 2008 From: camior at gmail.com (David Sankel) Date: Thu Nov 6 16:09:37 2008 Subject: [Haskell-cafe] ghc-6.11 + OpenGL/GLUT crashes on WinXP In-Reply-To: References: Message-ID: With ghc 6.10.1, the patches aren't necessary for the lasted releases of the bindings. I've put a walkthrough on my blog for the process of getting `freeglut+GLUT binding+GL binding+ghc 6.10.1` up and running. http://netsuperbrain.com/blog/ David On Tue, Oct 28, 2008 at 10:48 AM, David Sankel wrote: > My setup worked: > > - Windows XP. > - ghc-6.11.20081024 > - freeglut 2.4.0 > - darcs version of GLUT (with patched glutGetProcAddress [attached]) > - darcs version of OpenGL > > Getting freeglut going with ghc on windows is a bit involved. I could write > a walkthrough if there's enough interest. > > David > > 2008/10/25 Conal Elliott > >> I'm getting crashes from ghc-6.10.0.20081007 and ghc-6.11.20081024 when >> doing a very simple GLUT program (below) with OpenGL-2.2.1.1 and >> GLUT-2.1.1.2 (the latest from Hackage), running on WinXP. It works fine on >> ghc-6.9.20080622 . >> >> I'd appreciate hearing about other attempts with these versions on Windows >> systems. >> >> Thanks, - Conal >> >> >> import Graphics.UI.GLUT >> >> main :: IO () >> main = do putStrLn "Initializing" >> getArgsAndInitialize >> return () >> >> >> _______________________________________________ >> 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/20081106/e135f858/attachment.htm From pjdtech2000 at gmail.com Thu Nov 6 16:35:17 2008 From: pjdtech2000 at gmail.com (PJ Durai) Date: Thu Nov 6 16:30:03 2008 Subject: [Haskell-cafe] Problem compiling hdbc with GHC 6.10.1 in windows Message-ID: <4f712c6f0811061335n76ec546dl5c422b72ba7639ec@mail.gmail.com> Greetings I would like to report that I am not able to compile hdbc 1.1.5.0. $ runghc.exe Setup.lhs build Preprocessing library HDBC-1.1.5... Building HDBC-1.1.5... [1 of 6] Compiling Database.HDBC.ColTypes ( Database\HDBC\ColTypes.hs, dist\build\Database\HDBC\ColTypes.o ) [2 of 6] Compiling Database.HDBC.Statement ( Database\HDBC\Statement.hs, dist\build\Database\HDBC\Statement.o ) [3 of 6] Compiling Database.HDBC.Types ( Database\HDBC\Types.hs, dist\build\Database\HDBC\Types.o ) [4 of 6] Compiling Database.HDBC.DriverUtils ( Database\HDBC\DriverUtils.hs, dist\build\Database\HDBC\DriverUtils.o ) [5 of 6] Compiling Database.HDBC.Utils ( Database\HDBC\Utils.hs, dist\build\Database\HDBC\Utils.o ) Database\HDBC\Utils.hs:51:11: Not in scope: `catchDyn' Database\HDBC\Utils.hs:55:16: Not in scope: `catchDyn' Database\HDBC\Utils.hs:60:18: Not in scope: `dynExceptions' Environment: Windows XP SP2 GHC 6.10.1 thanks pj I had no problems compiling this with GHC 6.8. From jason.dusek at gmail.com Thu Nov 6 16:45:36 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Thu Nov 6 16:40:22 2008 Subject: [Haskell-cafe] pure programs In-Reply-To: References: <42784f260811041612i62346327uc8dd5ae919aea43f@mail.gmail.com> Message-ID: <42784f260811061345p31a1e23bj741e85855be90fcc@mail.gmail.com> Conal Elliott wrote: > To help me understand your question, would you be unhappy with > the following structure? > > -- runnable > main = interact f > -- composable > f = ... > > The discipline is to use interact (or another combinator) to > wrap a functional/composable/pure component like f into an > executable. Then give main to users and f to programmers. I'd like to be able to compose with systems not written in Haskell, though -- in short, I think of interact f as the composable, exportable part. My original email is motivated by concern about at what level a program is "pure" in the presence of conditional compilation (and dynamic linking, for that matter). I can not, for example, say all pure functions in my code, when used with the same Haskell library set, will return the same results on all platforms. So source code level purity is out. If we move to executable level purity, that seems plausible -- on a given platform, a given executable, if it executes all, will execute identically if it is statically linked with the C libs as well as the Haskell. This is not actually possible on Macs but whatever. The one corner case I had in mind was FreeBSD's Linux ABI compatibility, but I suspect that doesn't matter at all (not having any FreeBSD handy at the moment, I can not verify it). -- _jsn From jefferson.r.heard at gmail.com Thu Nov 6 17:08:39 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Thu Nov 6 17:03:25 2008 Subject: [Haskell-cafe] Anyone know why this always returns invalid texture objects? Message-ID: <4165d3a70811061408p6dd45271m22a171459de1a517@mail.gmail.com> import Graphics.UI.Gtk import Graphics.UI.Gtk.Glade import Graphics.UI.Gtk.OpenGL import qualified Graphics.Rendering.OpenGL as GL import Graphics.Rendering.OpenGL (($=)) main = do initGUI initGL GL.shadeModel $= GL.Flat GL.depthFunc $= Just GL.Less (window1,gui,dlgs) <- constructGUIObject (sX, sY) <- liftM (mapPair fromIntegral) . widgetGetSize . drawing_canvas $ gui -- get the canvas size for determining the part of the widget to repaint pb <- pixbufNew ColorspaceRgb False 8 (round pbWidth) (round pbHeight) pixbufFill pb 0 0 0 255 pxbufs <- initSubpixbufs pb texRows texCols textures <- GL.genObjectNames (texRows*texCols) print textures -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From bertram.felgenhauer at googlemail.com Thu Nov 6 18:37:13 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Thu Nov 6 18:32:08 2008 Subject: [Haskell-cafe] Writing an IRC bot, problems with plugins In-Reply-To: References: Message-ID: <20081106233713.GA10088@zombie.inf.tu-dresden.de> Alexander Foremny wrote: > I am writing an single server, multi channel IRC bot with the support of > plugins and limited plugin communication. With the plugin system I am facing > problems I cannot really solve myself. Here's an approach built completely around Data.Typeable. The fundamental idea is that a Plugin encompasses a set of interfaces of unknown types, which have Typeable instances. All we need is an operation to extract such an interface from a Plugin. data Plugin = Plugin { getInterface :: forall i. Typeable i => Maybe i } Then we can define the interfaces we want to use, for example: data BaseInterface = BaseInterface { identifier :: String, rawMessage :: (MonadIO m) => Message -> PL m () } deriving Typeable Sending a message to a plugin can be implemented as sendMessage :: Plugin -> Message -> PL m () sendMessage p msg = do let pI :: Maybe BaseInterface pI = getInterface p case pI of Nothing -> error "Plugin does not support BaseInterface" Just pI' -> rawMessage pI' msg A more complete example follows below. Does that help? Bertram ------------------------------------------------------------------------ {-# LANGUAGE GADTs, Rank2Types, DeriveDataTypeable #-} module PluginTest (main) where import Data.Typeable import Data.IORef import Control.Monad.Trans import Control.Monad.State import qualified Data.Map as M ------------------------------------------------------------------------ -- Types -- A Plugin is just a method that returns various interfaces. data Plugin = Plugin { getInterface :: forall i. Typeable i => Maybe i } -- The basic interface. -- -- It should be made a part of Plugin, but it's a queryable interface -- in this example for demonstration purposes. data BaseInterface = BaseInterface { identifier :: String, rawMessage :: (MonadIO m) => Message -> PL m () } deriving Typeable type Message = String type PL = StateT PluginConfig type PluginConfig = M.Map String Plugin ------------------------------------------------------------------------ -- Main -- look up a plugin by name findPlugin :: Monad m => String -> PL m (Maybe Plugin) findPlugin k = get >>= return . M.lookup k -- register a plugin registerPlugin :: MonadIO m => Plugin -> PL m () registerPlugin p = do -- note: 'getInterface' can return 'Nothing' - needs error checking let Just i = getInterface p modify (M.insert (identifier i) p) -- unregister, etc. main' :: MonadIO m => PL m () main' = do -- create two plugins (see below) and register them. a <- createAPlugin registerPlugin a b <- createBPlugin registerPlugin b -- extract base interfaces of a and b and send some messages -- (needs error checking) let aI, bI :: BaseInterface Just aI = getInterface a Just bI = getInterface b liftIO $ putStrLn "-> Sending message to A" rawMessage aI "dummy" liftIO $ putStrLn "-> Sending message to B" rawMessage bI "Hi, here's a message from B" liftIO $ putStrLn "-> Sending another message to A" rawMessage aI "dummy" main :: IO () main = evalStateT main' M.empty ------------------------------------------------------------------------ -- Plugin A -- -- This plugin provides an additional Interface that allows to -- query and change a string value in its state. data APlugin = APlugin (IORef String) data AInterface = AInterface { aGet :: (MonadIO m) => PL m String, aPut :: (MonadIO m) => String -> PL m () } deriving Typeable createAPlugin :: (MonadIO m) => PL m Plugin createAPlugin = do r <- liftIO (newIORef "initial state") let a = APlugin r return $ Plugin { getInterface = cast (aBase a) `mplus` cast (aInterface a) } aBase (APlugin r) = BaseInterface { identifier = "A", rawMessage = msg } where msg _ = liftIO $ do s <- readIORef r putStrLn ("A has state (" ++ s ++ ")!") aInterface :: APlugin -> AInterface aInterface (APlugin r) = AInterface { aGet = liftIO (readIORef r), aPut = \v -> liftIO (writeIORef r v) } ------------------------------------------------------------------------ -- Plugin B -- -- Plugin B knows about Plugin A and uses its additional interface for -- modifying its state createBPlugin :: (MonadIO m) => PL m Plugin createBPlugin = return $ Plugin { getInterface = cast bBase } bBase = BaseInterface { identifier = "B", rawMessage = msg } where msg s = do -- find "A" plugin Just a <- findPlugin "A" -- and get its additional interface let aI :: AInterface Just aI = getInterface a aPut aI s From nominolo at googlemail.com Thu Nov 6 18:41:30 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Nov 6 18:36:16 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: Haddock version 2.4.0 In-Reply-To: <200811061559.10325.g9ks157k@acme.softbase.org> References: <200811061559.10325.g9ks157k@acme.softbase.org> Message-ID: <916b84820811061541m56fd2d3fyf94b922b0181c9af@mail.gmail.com> [Redirecting to cafe@ since haskell@ is not meant for discussions] Sure, they are bad for one reason: you cannot link to a frame configuration directly. However, for this particular use case they are quite handy. There are some features missing (like hoogle integration) and some annoyances (if javascript is enabled, we show both a mini-synopsis, but this interacts badly with the back-button.) You can simulate this if you add a lot more javascript, have some kind of server, generate many more static pages, or use some CSS magic. But the implemented solution works and is reasonably useful. If someone wants to improve this I certainly don't mind. 2008/11/6 Wolfgang Jeltsch : > Am Donnerstag, 6. November 2008 00:21 schrieb David Waern: >> * Add framed view of the HTML documentation > > After many years with many people telling us that frames are bad, you add > frame support to Haddock? Hmm. > > Best wishes, > Wolfgang > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From nominolo at googlemail.com Thu Nov 6 18:44:19 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Nov 6 18:39:05 2008 Subject: [Haskell-cafe] Problem compiling hdbc with GHC 6.10.1 in windows In-Reply-To: <4f712c6f0811061335n76ec546dl5c422b72ba7639ec@mail.gmail.com> References: <4f712c6f0811061335n76ec546dl5c422b72ba7639ec@mail.gmail.com> Message-ID: <916b84820811061544t11c05acew5bd3746bcfc4baa8@mail.gmail.com> You need to use base-3. For a temporary fix, edit the file HDBC.cabal and change the base part of the "build-depends" to look like this: base == 3.*, (wherever it occurs) 2008/11/6 PJ Durai : > Greetings > > I would like to report that I am not able to compile hdbc 1.1.5.0. > > $ runghc.exe Setup.lhs build > Preprocessing library HDBC-1.1.5... > Building HDBC-1.1.5... > [1 of 6] Compiling Database.HDBC.ColTypes ( Database\HDBC\ColTypes.hs, > dist\build\Database\HDBC\ColTypes.o ) > [2 of 6] Compiling Database.HDBC.Statement ( > Database\HDBC\Statement.hs, dist\build\Database\HDBC\Statement.o ) > [3 of 6] Compiling Database.HDBC.Types ( Database\HDBC\Types.hs, > dist\build\Database\HDBC\Types.o ) > [4 of 6] Compiling Database.HDBC.DriverUtils ( > Database\HDBC\DriverUtils.hs, dist\build\Database\HDBC\DriverUtils.o ) > [5 of 6] Compiling Database.HDBC.Utils ( Database\HDBC\Utils.hs, > dist\build\Database\HDBC\Utils.o ) > Database\HDBC\Utils.hs:51:11: Not in scope: `catchDyn' > Database\HDBC\Utils.hs:55:16: Not in scope: `catchDyn' > Database\HDBC\Utils.hs:60:18: Not in scope: `dynExceptions' > > Environment: > Windows XP SP2 > GHC 6.10.1 > > thanks > pj > > I had no problems compiling this with GHC 6.8. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dons at galois.com Thu Nov 6 18:46:47 2008 From: dons at galois.com (Don Stewart) Date: Thu Nov 6 18:41:14 2008 Subject: [Haskell-cafe] Problem compiling hdbc with GHC 6.10.1 in windows In-Reply-To: <916b84820811061544t11c05acew5bd3746bcfc4baa8@mail.gmail.com> References: <4f712c6f0811061335n76ec546dl5c422b72ba7639ec@mail.gmail.com> <916b84820811061544t11c05acew5bd3746bcfc4baa8@mail.gmail.com> Message-ID: <20081106234647.GH4758@scytale.galois.com> Or build with --constraint='base<4' nominolo: > You need to use base-3. For a temporary fix, edit the file HDBC.cabal > and change the base part of the "build-depends" to look like this: > base == 3.*, (wherever it occurs) > > 2008/11/6 PJ Durai : > > Greetings > > > > I would like to report that I am not able to compile hdbc 1.1.5.0. > > > > $ runghc.exe Setup.lhs build > > Preprocessing library HDBC-1.1.5... > > Building HDBC-1.1.5... > > [1 of 6] Compiling Database.HDBC.ColTypes ( Database\HDBC\ColTypes.hs, > > dist\build\Database\HDBC\ColTypes.o ) > > [2 of 6] Compiling Database.HDBC.Statement ( > > Database\HDBC\Statement.hs, dist\build\Database\HDBC\Statement.o ) > > [3 of 6] Compiling Database.HDBC.Types ( Database\HDBC\Types.hs, > > dist\build\Database\HDBC\Types.o ) > > [4 of 6] Compiling Database.HDBC.DriverUtils ( > > Database\HDBC\DriverUtils.hs, dist\build\Database\HDBC\DriverUtils.o ) > > [5 of 6] Compiling Database.HDBC.Utils ( Database\HDBC\Utils.hs, > > dist\build\Database\HDBC\Utils.o ) > > Database\HDBC\Utils.hs:51:11: Not in scope: `catchDyn' > > Database\HDBC\Utils.hs:55:16: Not in scope: `catchDyn' > > Database\HDBC\Utils.hs:60:18: Not in scope: `dynExceptions' > > > > Environment: > > Windows XP SP2 > > GHC 6.10.1 > > > > thanks > > pj > > > > I had no problems compiling this with GHC 6.8. > > _______________________________________________ > > 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 pjdtech2000 at gmail.com Thu Nov 6 19:39:10 2008 From: pjdtech2000 at gmail.com (PJ Durai) Date: Thu Nov 6 19:33:55 2008 Subject: [Haskell-cafe] Problem compiling hdbc with GHC 6.10.1 in windows In-Reply-To: <916b84820811061544t11c05acew5bd3746bcfc4baa8@mail.gmail.com> References: <4f712c6f0811061335n76ec546dl5c422b72ba7639ec@mail.gmail.com> <916b84820811061544t11c05acew5bd3746bcfc4baa8@mail.gmail.com> Message-ID: <4f712c6f0811061639l7d33164je2d00306a9275456@mail.gmail.com> On Thu, Nov 6, 2008 at 4:44 PM, Thomas Schilling wrote: > You need to use base-3. For a temporary fix, edit the file HDBC.cabal > and change the base part of the "build-depends" to look like this: > base == 3.*, (wherever it occurs) > That worked. Thanks! > 2008/11/6 PJ Durai : >> Greetings >> >> I would like to report that I am not able to compile hdbc 1.1.5.0. >> >> $ runghc.exe Setup.lhs build >> Preprocessing library HDBC-1.1.5... >> Building HDBC-1.1.5... >> [1 of 6] Compiling Database.HDBC.ColTypes ( Database\HDBC\ColTypes.hs, >> dist\build\Database\HDBC\ColTypes.o ) >> [2 of 6] Compiling Database.HDBC.Statement ( >> Database\HDBC\Statement.hs, dist\build\Database\HDBC\Statement.o ) >> [3 of 6] Compiling Database.HDBC.Types ( Database\HDBC\Types.hs, >> dist\build\Database\HDBC\Types.o ) >> [4 of 6] Compiling Database.HDBC.DriverUtils ( >> Database\HDBC\DriverUtils.hs, dist\build\Database\HDBC\DriverUtils.o ) >> [5 of 6] Compiling Database.HDBC.Utils ( Database\HDBC\Utils.hs, >> dist\build\Database\HDBC\Utils.o ) >> Database\HDBC\Utils.hs:51:11: Not in scope: `catchDyn' >> Database\HDBC\Utils.hs:55:16: Not in scope: `catchDyn' >> Database\HDBC\Utils.hs:60:18: Not in scope: `dynExceptions' >> >> Environment: >> Windows XP SP2 >> GHC 6.10.1 >> >> thanks >> pj >> >> I had no problems compiling this with GHC 6.8. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > From bertram.felgenhauer at googlemail.com Thu Nov 6 21:15:31 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Thu Nov 6 21:10:25 2008 Subject: [Haskell-cafe] Anyone know why this always returns invalid texture objects? In-Reply-To: <4165d3a70811061408p6dd45271m22a171459de1a517@mail.gmail.com> References: <4165d3a70811061408p6dd45271m22a171459de1a517@mail.gmail.com> Message-ID: <20081107021531.GB10088@zombie.inf.tu-dresden.de> [CCing gtk2hs-users] Jefferson Heard wrote: > import Graphics.UI.Gtk > import Graphics.UI.Gtk.Glade > import Graphics.UI.Gtk.OpenGL > import qualified Graphics.Rendering.OpenGL as GL > import Graphics.Rendering.OpenGL (($=)) > > main = do > initGUI > initGL "initGL" may be slightly misleading - it initialises the gtkglext gtk+ extension. It does not create a GL context. > GL.shadeModel $= GL.Flat > GL.depthFunc $= Just GL.Less > (window1,gui,dlgs) <- constructGUIObject > (sX, sY) <- liftM (mapPair fromIntegral) . widgetGetSize . > drawing_canvas $ gui -- get the canvas size for determining the part > of the widget to repaint > pb <- pixbufNew ColorspaceRgb False 8 (round pbWidth) (round pbHeight) > pixbufFill pb 0 0 0 255 > pxbufs <- initSubpixbufs pb texRows texCols > textures <- GL.genObjectNames (texRows*texCols) > print textures There is no active GL context at this point. GtkGLExt creates new GL contexts for GL enabled widgets when they're realized - I think. I'm a bit fuzzy about the exact life time of the GL context. [1] After the context was created, you have to activate it before doing any GL operations. In Gtk2hs you can use the GLDrawingArea widget, which provides withGLDrawingArea for easy activation of the GL context. There's an example in the gtk2hs sources, in examples/opengl. Enabling GL for other widgets is not supported well at the moment. (There are low level bindings (using DrawWindow), but no generic binding to the higher level gtk_widget_set_gl_capability() call. Such support wouldn't be too hard to add, I think.) HTH, Bertram [1] see http://gtkglext.sourceforge.net/reference/gtkglext/gtkglext-gtkglwidget.html#gtk-widget-get-gl-context From jefferson.r.heard at gmail.com Thu Nov 6 21:57:59 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Thu Nov 6 21:52:45 2008 Subject: [Gtk2hs-users] [Haskell-cafe] Anyone know why this always returns invalid texture objects? In-Reply-To: <20081107021531.GB10088@zombie.inf.tu-dresden.de> References: <4165d3a70811061408p6dd45271m22a171459de1a517@mail.gmail.com> <20081107021531.GB10088@zombie.inf.tu-dresden.de> Message-ID: <4165d3a70811061857i7c6cf5bco8fe60d8932a60e28@mail.gmail.com> Ah, that's good to know. I thought initGL would create the context. Sorry to be unclear in the code I posted, but part of createGUIObject is a glDrawingAreaNew. It creates a drawing area, which is then stored in a giant UserInterface record. data UserInterface = MainWindow { ... , drawing_canvas :: GLDrawingArea } createGUIObject = do ... config <- glConfigNew ... canvas <- glDrawingAreaNew config return $ MainWindow { ... drawing_canvas = canvas .. } It seems that won't create the context? do I have to show the window first, or can I just do... withGLDrawingArea $ glGenObjects n ? Thanks! -- Jeff On Thu, Nov 6, 2008 at 9:15 PM, Bertram Felgenhauer wrote: > [CCing gtk2hs-users] > > Jefferson Heard wrote: >> import Graphics.UI.Gtk >> import Graphics.UI.Gtk.Glade >> import Graphics.UI.Gtk.OpenGL >> import qualified Graphics.Rendering.OpenGL as GL >> import Graphics.Rendering.OpenGL (($=)) >> >> main = do >> initGUI >> initGL > > "initGL" may be slightly misleading - it initialises the > gtkglext gtk+ extension. It does not create a GL context. > >> GL.shadeModel $= GL.Flat >> GL.depthFunc $= Just GL.Less >> (window1,gui,dlgs) <- constructGUIObject >> (sX, sY) <- liftM (mapPair fromIntegral) . widgetGetSize . >> drawing_canvas $ gui -- get the canvas size for determining the part >> of the widget to repaint >> pb <- pixbufNew ColorspaceRgb False 8 (round pbWidth) (round pbHeight) >> pixbufFill pb 0 0 0 255 >> pxbufs <- initSubpixbufs pb texRows texCols >> textures <- GL.genObjectNames (texRows*texCols) >> print textures > > There is no active GL context at this point. GtkGLExt creates > new GL contexts for GL enabled widgets when they're realized - > I think. I'm a bit fuzzy about the exact life time of the GL > context. [1] > > After the context was created, you have to activate it before > doing any GL operations. > > In Gtk2hs you can use the GLDrawingArea widget, which provides > withGLDrawingArea for easy activation of the GL context. > > There's an example in the gtk2hs sources, in examples/opengl. > > Enabling GL for other widgets is not supported well at the moment. > (There are low level bindings (using DrawWindow), but no generic > binding to the higher level gtk_widget_set_gl_capability() call. > Such support wouldn't be too hard to add, I think.) > > HTH, > > Bertram > > [1] see http://gtkglext.sourceforge.net/reference/gtkglext/gtkglext-gtkglwidget.html#gtk-widget-get-gl-context > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gtk2hs-users mailing list > Gtk2hs-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From mdmkolbe at gmail.com Fri Nov 7 00:51:46 2008 From: mdmkolbe at gmail.com (Michael D. Adams) Date: Fri Nov 7 00:46:31 2008 Subject: [Haskell-cafe] Bit Field Marshalling Message-ID: I'm writing a Storable instance for a data type that marshals to a C structure that contains bit fields such as the following: struct Foo { short x; short y; unsigned int a : 1; unsigned int b : 1; unsigned int c : 1; unsigned int d : 1; unsigned int reserved : 12; } For the "x" and "y" fields I've been using hsc2hs and something like #{peek Foo, x} to extract the fields. However, bit fields such as "a" have me stumped. But as far as I can tell, hsc2hs doesn't support bit fields. On top of that I'm not sure I can make any safe assumptions about what order the bit fields are packed (LSB or MSB first). Have others run into this problem before? What options are there for working around it? Michael D. Adams mdmkolbe@gmail.com From patai_gergely at fastmail.fm Fri Nov 7 01:11:19 2008 From: patai_gergely at fastmail.fm (Patai Gergely) Date: Fri Nov 7 01:06:04 2008 Subject: [Haskell-cafe] Problems with strictness analysis? In-Reply-To: References: <1225715493.29387.1282684893@webmail.messagingengine.com> Message-ID: <1226038279.3070.1283472211@webmail.messagingengine.com> > I tried your example in GHC 6.10 and isum appears to work fine. > The type of 10000000 gets defaulted to Integer, a specialized version > of isum for Integer is then created, the strictness analyzer > determines that isum is strict in s, and the code generator produces a > loop. (If you want to look at the assembly code, it's easier if you > make the type Int.) Thanks for checking it. I'll be curious to see any improvements the new version brings, but this sounds promising already. Gergely -- http://www.fastmail.fm - The way an email service should be From bulat.ziganshin at gmail.com Fri Nov 7 01:12:13 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Nov 7 01:08:05 2008 Subject: [Haskell-cafe] Bit Field Marshalling In-Reply-To: References: Message-ID: <326442596.20081107091213@gmail.com> Hello Michael, Friday, November 7, 2008, 8:51:46 AM, you wrote: > Have others run into this problem before? What options are there for > working around it? if your goal is to maximize portability and not speed, one option is to make another structure without bit fields, and add C helper function which converts from this intermediate structure into final one -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From DekuDekuplex at Yahoo.com Fri Nov 7 01:29:03 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Fri Nov 7 01:23:58 2008 Subject: [Haskell-cafe] Re: Haskell Quick Reference (1-page PDF) References: <20081106134113.114c0ef3.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <8dn7h415e3lac3vebod7ia5cijflvul455@4ax.com> The reference includes both pairs and triples under "Tuples," but only pairs under "Bigger types." You may wish to add the following example under "Bigger types": (a, b, c) triple of types a, b, and c (a, b, and c are type variables) Also, the examples under "Tuples" suggest that only pairs and triples are valid tuples, but in fact, n-tuples, where n is any positive integer other than 1, are valid tuples as well. You probably don't need to document the fact that 1-tuples are trivially isomorphic to values in parentheses, but you may wish to include the following line there (the specification of the range for the values of n being optional): (x1, x2, ..., xn) an n-tuple of values (n = 0 or n > 1) Accordingly, you may also wish to add the following corresponding line under "Bigger types" (again, the specification of the range for the values of n being optional): (a1, a2, ..., an) n-tuple of types a1, a2, ..., an (a1, a2, ..., an are type variables, n = 0 or n > 1) -- Benjamin L. Russell On Thu, 6 Nov 2008 13:41:13 +0000, Malcolm Wallace wrote: >Some time ago, there was a thread about a "CheatSheet" for Haskell >beginners. As I recall, the CheatSheet was more than 12 pages long. > >For a Haskell tutorial I was running at a conference recently, I needed >a "Quick Reference Guide" that would fit onto a single side of A4. So I >knocked one together quickly, and it is attached as a PDF. I send it to >this list, with permission for anyone to distribute it more widely as >they wish, in the hope that it might be useful. > >Doubtless it is incomplete, and I have no particular desire to fix >errors or maintain this document, so if anyone is interested and would >like to adopt it, I can pass on the editable sources. It was originally >created as an Apple Numbers spreadsheet (simply for speed of creation) >but could be converted to Excel or CSV, for import into other tools. > >Regards, > Malcolm From lutz at iks-jena.de Fri Nov 7 03:46:56 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri Nov 7 03:41:43 2008 Subject: [Haskell-cafe] Bit Field Marshalling References: Message-ID: * Michael D. Adams wrote: > But as far as I can tell, hsc2hs doesn't support bit > fields. On top of that I'm not sure I can make any safe assumptions > about what order the bit fields are packed (LSB or MSB first). C standard allows padding and reorder of struct entries in order to match alignment requirements. The only exeption are bitfields, which must not reordered and padded. This way bit fields are the only portable way to define the binary representation in C. Unfortunly the C standard does not specify any bit order for bit fields, but almost all implementations use the machine specific bit order, in order to ease access to multiple bits wide bit field and fill LSB to MSB. But there is no guarantee. I run into this problem when writing an low level kernel interface in SPARK. The ABI (binary representation) of the kernel API depends on the C compiler flags (i.e. #pragma packed). Especially kernels of commericial unicies might generate this problem, because the developer uses gcc instead of the native compiler. The only portable way to get access to C defined structures is involving a C compiler, either using hsc or a C helper module. From barsoap at web.de Fri Nov 7 04:41:01 2008 From: barsoap at web.de (Achim Schneider) Date: Fri Nov 7 04:35:57 2008 Subject: [Haskell-cafe] Re: Monad.Reader with updates References: <971065662.20081106144612@gmail.com> <4912E5B9.1010204@jellybean.co.uk> <20081106153942.7a1462ae@solaris> Message-ID: <20081107104101.0c50ec76@solaris> Maur____cio wrote: > > > >> [...] > >> > > Are you sure you don't want to use monad transformers? > > > > No. Do you have a sugestion on how could I do > it in this situation? > Not really, mainly because if monad transformers don't confuse you you should double-check if you aren't one of these SPJ clones he spawned to make Haskell succeed... But then, you either want a ReaderT r State s or StateT s Reader r, depending on how you want to write your code... the main thing that confuses me right now is that nesting order doesn't seem to matter that much in this case which makes me wonder if I really understood how those two nest. As another idea, you might want to use Parsec, you can regard it as a Reader on steroids and it also supports state, though you'll be conjuring up evil spirits if you try to influence parsing behaviour with it instead of just your return values. Two or even more passes are the way to go in such cases. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From barsoap at web.de Fri Nov 7 05:07:31 2008 From: barsoap at web.de (Achim Schneider) Date: Fri Nov 7 05:02:28 2008 Subject: [Haskell-cafe] Re: Bit Field Marshalling References: Message-ID: <20081107110731.6a33a972@solaris> "Michael D. Adams" wrote: > What options are there for working around it? > In case it's feasible, use http://www.matroska.org/technical/specs/rfc/index.html on both sides. I just can't stop to advertise that one. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From byorgey at seas.upenn.edu Fri Nov 7 08:54:39 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Fri Nov 7 08:49:24 2008 Subject: [Haskell-cafe] Re: Monad.Reader with updates In-Reply-To: <20081107104101.0c50ec76@solaris> References: <971065662.20081106144612@gmail.com> <4912E5B9.1010204@jellybean.co.uk> <20081106153942.7a1462ae@solaris> <20081107104101.0c50ec76@solaris> Message-ID: <20081107135439.GB11171@GRW057-25.cis.upenn.edu> On Fri, Nov 07, 2008 at 10:41:01AM +0100, Achim Schneider wrote: > > But then, you either want a ReaderT r State s or StateT s Reader r, > depending on how you want to write your code... the main thing that > confuses me right now is that nesting order doesn't seem to matter that > much in this case which makes me wonder if I really understood how > those two nest. >From the mtl documentation ([1], [2]): Reader r a =~ r -> a State s a =~ s -> (a, s) StateT s m a =~ s -> m (a, s) ReaderT r m a =~ r -> m a where =~ indicates isomorphism of types (up to newtype tags). So, ReaderT r (State s) a =~ r -> State s a =~ r -> s -> (a,s) and StateT s (Reader r) a =~ s -> Reader r (a,s) =~ s -> r -> (a,s) which are clearly isomorphic, just a simple function argument reordering. For some combinations of monad transformers (for example, StateT and MaybeT), the order of composition really does matter, but not for Reader and State. Moreover, if you make your new composed monad using a newtype with generalized deriving [3], the choice actually doesn't matter since you can write exactly the same code: newtype MyMonad a = My { unMy :: ReaderT r (State s) a } deriving (Functor, Monad, MonadReader r, MonadState s) You could also write the newtype the other way around, and still use it with the same code: you can just treat MyMonad as if it is both a Reader monad (ask, asks, local...) and a State monad (get, gets, put, modify...) with no icky lifts in sight. I don't know what this thread was originally about, but just thought I'd jump in to clarify. =) -Brent [1] http://hackage.haskell.org/packages/archive/mtl/1.1.0.1/doc/html/Control-Monad-State-Lazy.html [2] http://hackage.haskell.org/packages/archive/mtl/1.1.0.1/doc/html/Control-Monad-Reader.html [3] http://cale.yi.org/index.php/How_To_Use_Monad_Transformers From briqueabraque at yahoo.com Fri Nov 7 11:16:39 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Fri Nov 7 11:11:43 2008 Subject: [Haskell-cafe] Re: Monad.Reader with updates In-Reply-To: <2f9b2d30811061104m12257cb6pc6d4fdcb74544819@mail.gmail.com> References: <971065662.20081106144612@gmail.com> <4912E5B9.1010204@jellybean.co.uk> <2f9b2d30811061104m12257cb6pc6d4fdcb74544819@mail.gmail.com> Message-ID: > Hi Mauricio. What you want actually already exists in QuickCheck as > the "Gen" monad. > > newtype Gen a > = Gen (Int -> StdGen -> a) > > instance Monad Gen where > return a = Gen (\n r -> a) > Gen m >>= k = > Gen (\n r0 -> let (r1,r2) = split r0 > Gen m' = k (m n r1) > in m' n r2) > > (...) Nice. I think that's exactly what I was trying to do. > You could also implement this as a variation on the State monad if you > wanted to avoid using split: (...) Yes. After Brent's explanation I finally realized State was the perfect option. Maybe it should also be better for QuickCheck. I just didn't know it? There are many things in the standard library that do nice things, but I don't understand them until I write a few hundred lines trying to do what they do :) Thanks for your support and patience, Maur?cio From westondan at imageworks.com Fri Nov 7 12:56:56 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri Nov 7 12:51:45 2008 Subject: [Haskell-cafe] Bit Field Marshalling In-Reply-To: References: Message-ID: <49148168.90305@imageworks.com> > C standard allows padding and reorder of struct entries Almost. The ISO C standard does allow structs padding, but *not* reordering: http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf ISO/IEC 9899:1999 C Standard ?6.7.2.1.13 "Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning." Dan Lutz Donnerhacke wrote: > * Michael D. Adams wrote: >> But as far as I can tell, hsc2hs doesn't support bit >> fields. On top of that I'm not sure I can make any safe assumptions >> about what order the bit fields are packed (LSB or MSB first). > > C standard allows padding and reorder of struct entries in order to match > alignment requirements. The only exeption are bitfields, which must not > reordered and padded. This way bit fields are the only portable way to > define the binary representation in C. Unfortunly the C standard does not > specify any bit order for bit fields, but almost all implementations use > the machine specific bit order, in order to ease access to multiple bits > wide bit field and fill LSB to MSB. But there is no guarantee. From andrewcoppin at btinternet.com Fri Nov 7 17:11:10 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri Nov 7 17:05:50 2008 Subject: [Haskell-cafe] Convolution Message-ID: <4914BCFE.5090204@btinternet.com> A simple and straight-forward way to define the DSP operations of correlation and convolution is as follows: correlate1 :: [Double] -> [Double] -> Double correlate1 ks = sum . zipWith (*) ks correlate :: [Double] -> [Double] -> [Double] correlate ks [] = [] correlate ks xs = correlate1 ks xs : correlate ks (tail xs) convolute :: [Double] -> [Double] -> [Double] convolute ks = correlate (reverse ks) This very simple code work - and actually works quite well. It has the nice property of generating output from input lazily, as it is demanded. If the correlate function could be altered to use Prelude list functions only, I would think the above code works quite well with stream fusion too. (Presumably you could do this using "inits" or something?) Assuming DPH ever becomes a reality, how would you implement the above with it? (My intuition tells me that unless you have a really *big* filter kernel, breaking correlate1 into parallel chunks is too granular. However, each call to correlate1 could be run independently, presumably confering a more or less linear speedup. Unless having two cores writing to the same memory page is going to upset the cache system...) Presumably if you want to use parallel arrays, then the data must all exist in memory at once, and any chunking must be implemented manually and tediously? From lemming at henning-thielemann.de Fri Nov 7 17:35:54 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Nov 7 17:30:38 2008 Subject: [Haskell-cafe] Convolution In-Reply-To: <4914BCFE.5090204@btinternet.com> References: <4914BCFE.5090204@btinternet.com> Message-ID: On Fri, 7 Nov 2008, Andrew Coppin wrote: > A simple and straight-forward way to define the DSP operations of correlation > and convolution is as follows: > > correlate1 :: [Double] -> [Double] -> Double > correlate1 ks = sum . zipWith (*) ks > > correlate :: [Double] -> [Double] -> [Double] > correlate ks [] = [] > correlate ks xs = correlate1 ks xs : correlate ks (tail xs) > > convolute :: [Double] -> [Double] -> [Double] > convolute ks = correlate (reverse ks) I think the verb is 'convolve'. > This very simple code work - and actually works quite well. It has the nice > property of generating output from input lazily, as it is demanded. If ks is infinite it will not work. I have an implementation that works, but it computes something little different, see 'mul' in: http://darcs.haskell.org/htam/src/Polynomial.hs > If the correlate function could be altered to use Prelude list functions > only, I would think the above code works quite well with stream fusion > too. (Presumably you could do this using "inits" or something?) You mean 'tails' ? Would be rather straight-forward. From andrewcoppin at btinternet.com Fri Nov 7 17:39:02 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri Nov 7 17:33:41 2008 Subject: [Haskell-cafe] Convolution In-Reply-To: References: <4914BCFE.5090204@btinternet.com> Message-ID: <4914C386.5060306@btinternet.com> Henning Thielemann wrote: > > I think the verb is 'convolve'. Possibly. > If ks is infinite it will not work. Indeed. >> If the correlate function could be altered to use Prelude list >> functions only, I would think the above code works quite well with >> stream fusion too. (Presumably you could do this using "inits" or >> something?) > > You mean 'tails' ? Would be rather straight-forward. Hmm... Off the top of my head, I'm not sure which would be the correct one... Either way, I haven't tried it, but it looks like it shouldn't be hard. From dons at galois.com Fri Nov 7 19:47:46 2008 From: dons at galois.com (Don Stewart) Date: Fri Nov 7 19:42:30 2008 Subject: [Haskell-cafe] performance difference for binary-0.4.3.1 with ghc-6.8.3 and ghc-6.10 In-Reply-To: <9979e72e0810280938y4b16bd40l3faa826013e60432@mail.gmail.com> References: <9979e72e0810260936o2ac24eefm5c2941fcf8825e2b@mail.gmail.com> <57526e770810261734l741c869gcb39a47c890e9b54@mail.gmail.com> <9979e72e0810280938y4b16bd40l3faa826013e60432@mail.gmail.com> Message-ID: <20081108004746.GJ5979@scytale.galois.com> jwlato: > On Mon, Oct 27, 2008 at 12:34 AM, Alexander Dunlap > wrote: > > On Sun, Oct 26, 2008 at 9:36 AM, John Lato wrote: > >> Hello, > >> > >> I was experimenting with using ghc-6.10.0.20081007 on a project, and > >> it seems that binary-0.4.3.1 has markedly worse performance in certain > >> cases. With the following simple test: > >> > >>> import qualified Data.ByteString.Lazy as L > >>> import Data.Binary > >>> import Data.Binary.Get > >>> import Control.Monad > >>> > >>> main :: IO () > >>> main = do > >>> b <- L.readFile "some_binary_file" > >>> putStrLn $ show $ runGet getter b > >> > >>> getter :: Get [Word16] > >>> getter = replicateM 1000000 getWord16le > >> > >> running this program compiled with ghc-6.10 takes about 4 times as > >> long (and consumes much more memory) as when compiled with ghc-6.8.3. > >> The extra time appears to be proportional to the number of elements > >> processed in the Get. Running the programs with -hT shows a clear > >> memory difference, which I think is the source of the problem. I've > >> placed pdfs of that output at https://webspace.utexas.edu/latojw/data/ > >> > >> The difference seems to manifest itself only when the elements are > >> actually processed; changing "show $ runGet " to "show $ length $ > >> runGet " is slightly faster in 6.10. > >> > >> I was working on an Intel Mac with OS 10.4, binary-0.4.3.1, and > >> bytestring-0.9.1.4. Can anyone confirm this, or suggest what might be > >> the difference? > >> > >> Thank you, > >> John Lato > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe@haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > >> > > > > With GHC 6.8.2: > > > > test: too few bytes. Failed reading at byte position 1613914 > > > > real 0m27.573s > > user 0m12.917s > > sys 0m0.087s > > > > With GHC 6.11.20081003: > > > > test: too few bytes. Failed reading at byte position 1613914 > > > > real 0m21.528s > > user 0m14.759s > > sys 0m0.135s > > > > I'm not using the exact same versions as you are, but I seem to be > > getting different results. > > > > Hi Alexander, > > Thanks for trying this out. Based on your error, I'd guess that the > file isn't large enough to read all the requested data. In my case, > it was about 70MB. You could try reading from /dev/random, or rather > than reading from a file, use something like > > >> test_pure = let b = Data.ByteString.Lazy.repeat 1 in putStrLn $ show $ runGet getter b > > I haven't tried a pure version myself, so I don't know what to expect > from it. Something to do tonight... > I can reproduce the slowdown with ghc 6.10 in the binary benchmark suite. Investigating. -- Don From mdmkolbe at gmail.com Fri Nov 7 21:42:02 2008 From: mdmkolbe at gmail.com (Michael D. Adams) Date: Fri Nov 7 21:36:45 2008 Subject: [Haskell-cafe] Bit Field Marshalling In-Reply-To: References: Message-ID: On Fri, Nov 7, 2008 at 3:46 AM, Lutz Donnerhacke wrote: > * Michael D. Adams wrote: >> But as far as I can tell, hsc2hs doesn't support bit >> fields. On top of that I'm not sure I can make any safe assumptions >> about what order the bit fields are packed (LSB or MSB first). > ... > > The only portable way to get access to C defined structures is involving > a C compiler, either using hsc or a C helper module. I don't think hsc2hs provides that support natively. (I would love to be proven wrong about that.) However, I think it would be reasonable to extend hsc2hs. I've attached a basic draft of an extension that would make hsc2hs support this. Basically this extra template file adds #{peek_bit ,} and #{poke_bit ,} which present basically the same interface as #{peek} and #{poke} but specialized with some extra smarts to support bit-fields. I probably won't have time to refine this code, but if others find this code to be useful, feel free to take and use code and maybe we can get some proper support into hsc2hs someday. *nudge nudge* Michael D. Adams adamsmd@cs.indiana.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: template-bit-hsc.h Type: text/x-chdr Size: 3043 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081107/07b84751/template-bit-hsc.bin From briqueabraque at yahoo.com Sat Nov 8 11:21:25 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Sat Nov 8 11:16:24 2008 Subject: [Haskell-cafe] Dealing with CStringLen Message-ID: Hi, How is CStringLen supposed to be used? The only usual C string I'm familiar with is the null terminated sequence of chars. I remember some Pascal version where the first 2 bytes were used as an integer counting the following characters. What is the convention used in Foreign.C.String? I have a C function signature like this: void function (int,const void*,int,const void*) where each (int,const void*) pair is a string. Can (should) I use CStringLen here? How? Thanks, Maur?cio From dons at galois.com Sat Nov 8 13:35:31 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 8 13:30:24 2008 Subject: [Haskell-cafe] Haskell Quick Reference (1-page PDF) In-Reply-To: <20081106134113.114c0ef3.Malcolm.Wallace@cs.york.ac.uk> References: <20081106134113.114c0ef3.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20081108183531.GA15146@scytale.galois.com> Malcolm.Wallace: > Some time ago, there was a thread about a "CheatSheet" for Haskell > beginners. As I recall, the CheatSheet was more than 12 pages long. > > For a Haskell tutorial I was running at a conference recently, I needed > a "Quick Reference Guide" that would fit onto a single side of A4. So I > knocked one together quickly, and it is attached as a PDF. I send it to > this list, with permission for anyone to distribute it more widely as > they wish, in the hope that it might be useful. > wonderful. recorded on the wiki, http://haskell.org/haskellwiki/Image:QuickReference.pdf From byorgey at seas.upenn.edu Sat Nov 8 14:53:37 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Nov 8 14:48:17 2008 Subject: [Haskell-cafe] Haskell Weekly News: Issue 92 - November 8, 2008 Message-ID: <20081108195336.GA15863@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20081108 Issue 92 - November 08, 2008 --------------------------------------------------------------------------- Welcome to issue 92 of HWN, a newsletter covering developments in the [1]Haskell community. GHC 6.10 is released!! Go forth and drool over its new features. Be sure to have the editline libraries (libedit-dev on Debian/Ubuntu, for example) installed before you try building it. Announcements GHC version 6.10.1. Ian Lynagh [2]announced the release of [3]GHC version 6.10.1! This new major release features a number of significant changes, including wild-card patterns, punning, and field disambiguation in record syntax; generalised quasi-quotes; generalised SQL-like list comprehensions; view patterns; a complete reimplementation of type families; parallel garbage collection; a new extensible exception framework; a more user-friendly API; included Data Parallel Haskell (DPH); and more! See [4]the full release notes for more information. new community.haskell.org features: webspace, mailing lists. Ian Lynagh [5]announced that the community server, http://community.haskell.org/, has two new features for hosted projects: project webspace, and project mailing lists. GHC blog. Simon Marlow [6]has set up a [7]GHC blog. This is for all things related to GHC, particularly people working on GHC to blog about what they're up to. If you want a write-bit, sign up for a [8]wordpress account, let Simon know your account name, and blog away! The GHC blog should be syndicated on [9]Planet Haskell soon. Haddock 2.4.0. David Waern [10]announced a [11]new release of [12]Haddock, the Haskell documentation tool. This is a later version than the one shipped with GHC 6.10.1, which is version 2.3.0. That version will not be released on Hackage since it only builds with GHC 6.10.1 (by accident, actually). Besides adding back support for earlier GHC versions, this release contains some more fixes and support for HTML frames. htags-1.0. David Sankel [13]announced the [14]htags package, a tag file generator to enable extra functionality in editors like vim. It expands upon hasktags by using a full Haskell 98 parser and options for recursion. Haskell Quick Reference (1-page PDF). Malcolm Wallace [15]sent a 1-page Haskell quick reference prepared for a recent Haskell tutorial. Permission is granted for anyone to distribute it more widely as they wish, in the hope that it might be useful. Editable sources can be passed along if anyone would like to extend it. Proposal for associated type synonyms in Template Haskell. Thomas van Noort [16]submitted a proposal for adding associated type synonyms to Template Haskell. Comments are welcomed. announce [("InfixApplicative", 1.0), ("OpenGLCheck", 1.0), ("obj", 0.1)]. Thomas Davie [17]announced the upload of a few packages to Hackage which he has produced while working at Anygma. [18]obj-0.1 is a library for loading and writing obj 3D models; [19]OpenGLCheck-1.0 is a micro-package containing instances of Arbitrary for the data structures provided in Graphics.Rendering.OpenGL; and [20]InfixApplicative-1.0 is a second micro-package containing a pair of functions (<^) and (^>) which can be used to provide an infix version of liftA2 applied to an operator. Graphalyze-0.5 and SourceGraph-0.3. Ivan Lazar Miljenovic [21]announced the latest versions of [22]Graphalyze and [23]SourceGraph, which fix a couple of bugs in the previous versions. zlib and bzlib 0.5 releases. Duncan Coutts [24]announced updates to the [25]zlib and [26]bzlib packages, featuring a slightly nicer extended API. The simple API that most packages use is unchanged. There is also a new parameter to control the size of the first output buffer; this lets applications save memory when they happen to have a good estimate of the output size. Discussion Efficient parallel regular expressions. Martijn van Steenbergen [27]asked about efficiently running multiple regular expressions in parallel, leading to an interesting discussion of regular expressions and various parsing methods and libraries. Problems with strictness analysis?. Patai Gergely started an informative [28]discussion about strictness, laziness, strictness analysis, and compiler optimization. If you don't know a lot about these topics but would like to learn, this thread is a good starting point! Jobs 1-year postdoc position in Chalmers Functional Programming group. John Hughes [29]announced a position for a post-doctoral researcher with the Chalmers Functional Programming Group, with a one-year tax-free stipend funded by Intel. The funded project will develop a Domain Specific Language (DSL) for high level modelling, design and analysis of hardware and microarchitectures. Blog noise [30]Haskell news from the [31]blogosphere. * Edward Kmett: [32]Still Alive. Edward is still alive but sadly lost a few recursion scheme posts. =( * >>> Max Rabkin: [33]Beautiful folding. A very cool post about composable folds! * Eric Kow (kowey): [34]timesheet helper. * Philip Wadler: [35]A bizarre function over streams. * David Sankel: [36]Introducing Reactive: Events. A very readable introduction to the Reactive library. I look forward to reading more! * "FP Lunch": [37]Numbers vs Sets. * Mark Jason Dominus: [38]Addenda to recent articles 200810. * Darcs: [39]darcs weekly news #11. * >>> Ken G.: [40]Haskell?. Ken shares some thoughts on Real World Haskell. * Real-World Haskell: [41]Some early reviews. * David Sankel: [42]freeglut + Windows + HOpenGL + HGLUT. * GHC mutterings: [43]GHC 6.10.1 is out!. * Chung-chieh Shan: [44]Cognitive jobs. * London Haskell Users Group: [45]Duncan Coutts: The Haskell Platform. The abstract for Duncan's talk at the London HUG. * Well-Typed.Com: [46]GHC 6.10.1 released!. * Well-Typed.Com: [47]Haskell Platform talk at the London Haskell Users Group. * Mark Wassell: [48]GIS with Haskell 1. * >>> phoenix: [49]Haskell Tricks: Indexing a List. Getting the index of an element satisfying a predicate by zipping. * JP Moresmau: [50]Haskell for counting votes!. JP illustrates five different voting methods with some Haskell implementations. * Ivan Lazar Miljenovic: [51]Graph Theoretic Analysis of Relationships within Discrete Data. * Braden Shepherdson: [52]Pimp Your XMonad #1: Status bars. The first in a planned series of articles on not-so-well-known ways to extend your xmonad configuration. * >>> Cory: [53]Euler and Haskell. Cory just started learning Haskell (a "fun, slightly ridiculous language") via Project Euler. * >>> Sadek Drobi: [54]Code Safety and Correctness is a matter of Mindset Cultured by the Language. * Well-Typed.Com: [55]zlib and bzlib package updates. * >>> Bryan St. Amour: [56]Haskell Solution To The Farmer Problem. * >>> Nathan Hartman: [57]Haskell, Lambert, and the Clarke Ellipsoid. Nathan has started porting a map projection library to Haskell. * David Sankel: [58]Analysis of lazy-stream programs.. Quotes of the Week * Cory: Any language which makes frequent use of monads, functors and has a wikibook describing its relation to category theory is the result of an evil genius (or several, to be precise). * mmorrow: in langs with dependent types, you can just map numbers directly to types instead of having to ride a unicycle along a tightrope while battling an unruly gang of monkeys with knives. * conal: -fsemantics-shemantics * roconnor: all sorts of wonderful things could be done if we are less anal about bottoms. No pun intended. About the Haskell Weekly News New editions are posted to [59]the Haskell mailing list as well as to [60]the Haskell Sequence and [61]Planet Haskell. [62]RSS is also available, and headlines appear on [63]haskell.org. To help create new editions of this newsletter, please see the information on [64]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [65]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/15591 3. http://www.haskell.org/ghc/ 4. http://haskell.org/ghc/docs/6.10.1/html/users_guide/release-6-10-1.html 5. http://article.gmane.org/gmane.comp.lang.haskell.general/16600 6. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/15603 7. http://ghcmutterings.wordpress.com/ 8. http://wordpress.com/ 9. http://planet.haskell.org/ 10. http://www.haskell.org//pipermail/haskell-cafe/2008-November/050271.html 11. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.4.0 12. http://www.haskell.org/haddock 13. http://article.gmane.org/gmane.comp.lang.haskell.general/16582 14. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/htags 15. http://article.gmane.org/gmane.comp.lang.haskell.cafe/47344 16. http://article.gmane.org/gmane.comp.lang.haskell.cafe/47301 17. http://article.gmane.org/gmane.comp.lang.haskell.cafe/47241 18. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/obj 19. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OpenGLCheck 20. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/InfixApplicative 21. http://article.gmane.org/gmane.comp.lang.haskell.cafe/47171 22. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Graphalyze 23. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SourceGraph 24. http://article.gmane.org/gmane.comp.lang.haskell.cafe/47144 25. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/zlib 26. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bzlib 27. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/47242 28. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/47183 29. http://article.gmane.org/gmane.comp.lang.haskell.general/16596 30. http://planet.haskell.org/ 31. http://haskell.org/haskellwiki/Blog_articles 32. http://comonad.com/reader/2008/still-alive/ 33. http://squing.blogspot.com/2008/11/beautiful-folding.html 34. http://koweycode.blogspot.com/2008/11/timesheet-wishlist.html 35. http://wadler.blogspot.com/2008/11/bizarre-function-over-streams.html 36. http://netsuperbrain.com/blog/posts/introducing-reactive-events/ 37. http://sneezy.cs.nott.ac.uk/fplunch/weblog/?p=114 38. http://blog.plover.com/addenda/200810.html 39. http://blog.darcs.net/2008/11/darcs-weekly-news-11.html 40. http://monolith149daily.blogspot.com/2008/11/haskell.html 41. http://www.realworldhaskell.org/blog/2008/11/06/some-early-reviews/ 42. http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/ 43. http://ghcmutterings.wordpress.com/2008/11/05/ghc-6101-is-out/ 44. http://conway.rutgers.edu/~ccshan/wiki/blog/posts/Cognitive_jobs/ 45. http://www.londonhug.net/2008/11/04/duncan-coutts-the-haskell-platform/ 46. http://blog.well-typed.com/2008/11/ghc-6101-released/ 47. http://blog.well-typed.com/2008/11/haskell-platform-talk-at-the-london-haskell-users-group/ 48. http://pound-stone.blogspot.com/2008/11/gis-with-haskell-1.html 49. http://phoenixblitz.blogspot.com/2008/11/haskell-tricks-indexing-list.html 50. http://jpmoresmau.blogspot.com/2008/11/haskell-for-counting-votes.html 51. http://ivanmiljenovic.wordpress.com/2008/11/03/graph-theoretic-analysis-of-relationships-within-discrete-data/ 52. http://braincrater.wordpress.com/2008/11/02/pimp-your-xmonad-1-status-bars/ 53. http://onag.blogspot.com/2008/11/euler-and-haskell.html 54. http://sadekdrobi.com/2008/11/02/code-safety-and-correctness-is-a-matter-of-mindset-cultured-by-the-language/ 55. http://blog.well-typed.com/2008/11/zlib-and-bzlib-package-updates/ 56. http://bryanstamour.com/?p=49 57. http://parsemymonad.blogspot.com/2008/10/haskell-lambert-and-clarke-ellipsoid.html 58. http://netsuperbrain.com/blog/posts/analysis-of-lazy-stream-programs/ 59. http://www.haskell.org/mailman/listinfo/haskell 60. http://sequence.complete.org/ 61. http://planet.haskell.org/ 62. http://sequence.complete.org/node/feed 63. http://haskell.org/ 64. http://haskell.org/haskellwiki/HWN 65. http://code.haskell.org/~byorgey/code/hwn/ From drl at cs.cmu.edu Sat Nov 8 14:56:57 2008 From: drl at cs.cmu.edu (Dan Licata) Date: Sat Nov 8 14:51:40 2008 Subject: [Haskell-cafe] view patterns In-Reply-To: <89ca3d1f0811051315q27fed7edwf6433eba3c64b089@mail.gmail.com> References: <1ff5dedc0811042134x3e5c3f67ld12408c54037a629@mail.gmail.com> <89ca3d1f0811051315q27fed7edwf6433eba3c64b089@mail.gmail.com> Message-ID: <20081108195657.GA28476@cs.cmu.edu> Hi everyone, Yes, the current overlap checker thinks all view patterns are overlapped. The pattern overlap/exhaustiveness checker needs to be rewritten to account for GADTs and view patterns. You can use -fno-warn-overlapping-patterns to suppress these warning (along with any actual overlaps, though, unfortunately). -Dan On Nov05, Cale Gibbard wrote: > 2008/11/5 Cetin Sert : > > :1:4: > > Warning: Pattern match(es) are overlapped > > In the definition of `emp': > > emp ((has -> True)) = ... > > emp ((has -> False)) = ... > > > > Why do I get this error in ghc or when I try to compile a file with view > > patterns? > > (using -fglasgow-exts and -XViewPatterns, ghc 6.10.1) > > This is a bug which appears to be known about: > http://hackage.haskell.org/trac/ghc/ticket/2395 > > - Cale > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jgm at berkeley.edu Sat Nov 8 15:32:44 2008 From: jgm at berkeley.edu (John MacFarlane) Date: Sat Nov 8 15:27:27 2008 Subject: [Haskell-cafe] ANNOUNCE: gitit 0.2 release - wiki using HAppS, git, pandoc Message-ID: <20081108203244.GA6568@berkeley.edu> I've uploaded an early version of gitit, a Haskell wiki program, to HackageDB. Gitit uses HAppS as a webserver, git for file storage, pandoc for rendering the (markdown) pages, and highlighting-kate for highlighted source code. Some nice features of gitit: - Pages and uploaded files are stored in a git repository and may be added, deleted, and modified directly using git. - Pages may be organized into subdirectories. - Pandoc's extended version of markdown is used, so you can do tables, footnotes, syntax-highlighted code blocks, and LaTeX math. (And you can you pandoc to convert pages into many other formats.) - Math is rendered using jsMath (which must be installed separately). - Source code files in the repository are automatically rendered with syntax highlighting (plain/text version is also available). You can check it out on my webserver: http://johnmacfarlane.net:5001/ Or try it locally: cabal update cabal install pandoc -fhighlighting cabal install gitit gitit # note: this will create two subdirectories in the working directory # then browse to http://localhost:5001. There's a git repository at http://github.com/jgm/gitit/tree/master. Comments and patches are welcome. John From waldmann at imn.htwk-leipzig.de Sat Nov 8 16:41:34 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Sat Nov 8 16:36:18 2008 Subject: [Haskell-cafe] generalized list comprehensions Message-ID: <4916078E.7090004@imn.htwk-leipzig.de> Looking at this funny new feature http://haskell.org/ghc/docs/6.10.1/html/users_guide/syntax-extns.html#generalised-list-comprehensions I have just one question - why doesn't this work with the do-notation? I avoid list comprehensions because I feel that "return" belongs at the end, not in front. If I recall correctly, "putting the SQL-select where it belongs" is a slogan used by Hijlsberg to justify the LINQ syntax for C#, and of course he is right. Now ghc copies LINQ (syntactically), but stops halfway? Just wondering - J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081108/42eea36f/signature.bin From lgreg.meredith at biosimilarity.com Sat Nov 8 17:31:11 2008 From: lgreg.meredith at biosimilarity.com (Greg Meredith) Date: Sat Nov 8 17:25:53 2008 Subject: [Haskell-cafe] ANNOUNCE: rewriting-0.1 Message-ID: <5de3f5ca0811081431m1513d463ye66df87c030d3d4@mail.gmail.com> Thomas, Did you explore nominal rewrite at all? Do you know if it might be possible to use the scrap-your-nameplate package to implement some useful subset of the nominal rewrite machinery? 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/20081108/5fb14b97/attachment.htm From batterseapower at hotmail.com Sat Nov 8 18:43:52 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Sat Nov 8 18:38:31 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <4916078E.7090004@imn.htwk-leipzig.de> References: <4916078E.7090004@imn.htwk-leipzig.de> Message-ID: <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> 2008/11/8 Johannes Waldmann : > Looking at this funny new feature > http://haskell.org/ghc/docs/6.10.1/html/users_guide/syntax-extns.html#generalised-list-comprehensions > I have just one question - why doesn't this work with the do-notation? > > I avoid list comprehensions because I feel that > "return" belongs at the end, not in front. > > If I recall correctly, "putting the SQL-select where it belongs" > is a slogan used by Hijlsberg to justify the LINQ syntax for C#, > and of course he is right. > > Now ghc copies LINQ (syntactically), but stops halfway? Hi Johannes, There is no technical reason the syntax could not be extended to do notation - see the discussion by Michael Adams on the http://haskell.org/haskellwiki/Simonpj/Talk:ListComp page for a taste of how that would work (note that his translation is however not totally correct, IIRC). The only reason that I didn't actually implement this feature is that neither I nor SPJ could think of a use case for this syntax outside the list monad. I don't think we considered the possibility you might use do notation for the list monad, as it's not an idiom that seems to occur often. If you can come up with such a use case I could probably find the time to implement the extra translation steps! On reflection, it does seem a bit like an annoying irregularity to the implementation. Cheers, Max From mwassell at bigpond.net.au Sat Nov 8 18:51:55 2008 From: mwassell at bigpond.net.au (Mark Wassell) Date: Sat Nov 8 18:46:45 2008 Subject: [Haskell-cafe] Physics engines purely in Haskell? Message-ID: <4916261B.6050806@bigpond.net.au> Has anyone thought about or embarked on the task of developing a 2D or 3D physics engine purely in Haskell? There is Hipmunk but I'm wondering about a purely Haskell implementation; possibly a port of Chipmunk to Haskell. Mark From dons at galois.com Sat Nov 8 18:53:55 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 8 18:48:50 2008 Subject: [Haskell-cafe] Physics engines purely in Haskell? In-Reply-To: <4916261B.6050806@bigpond.net.au> References: <4916261B.6050806@bigpond.net.au> Message-ID: <20081108235355.GG15443@scytale.galois.com> mwassell: > Has anyone thought about or embarked on the task of developing a 2D or > 3D physics engine purely in Haskell? > > There is Hipmunk but I'm wondering about a purely Haskell > implementation; possibly a port of Chipmunk to Haskell. http://haskell.org/haskellwiki/Hpysics "Hpysics is a physics engine to be written using Data Parallel Haskell during Google Summer of Code 2008. " From dons at galois.com Sat Nov 8 19:12:35 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 8 19:07:15 2008 Subject: [Haskell-cafe] ANNOUNCE: gitit 0.2 release - wiki using HAppS, git, pandoc In-Reply-To: <20081108203244.GA6568@berkeley.edu> References: <20081108203244.GA6568@berkeley.edu> Message-ID: <20081109001235.GH15443@scytale.galois.com> jgm: > I've uploaded an early version of gitit, a Haskell wiki program, to > HackageDB. Gitit uses HAppS as a webserver, git for file storage, > pandoc for rendering the (markdown) pages, and highlighting-kate for > highlighted source code. Awesome. Well done, as always, John! -- Don From claudiusmaximus at goto10.org Sat Nov 8 19:23:04 2008 From: claudiusmaximus at goto10.org (Claude Heiland-Allen) Date: Sat Nov 8 19:17:45 2008 Subject: [Haskell-cafe] Dealing with CStringLen In-Reply-To: References: Message-ID: <49162D68.1080602@goto10.org> Maur??cio wrote: > Hi, > > How is CStringLen supposed to be used? The only > usual C string I'm familiar with is the null > terminated sequence of chars. I remember some > Pascal version where the first 2 bytes were used > as an integer counting the following characters. > What is the convention used in Foreign.C.String? the docs (via Hoogle) tell me: withCStringLen :: String -> (CStringLen -> IO a) -> IO a type CStringLen = (Ptr CChar, Int) > I have a C function signature like this: > > void function (int,const void*,int,const void*) > > where each (int,const void*) pair is a string. > Can (should) I use CStringLen here? How? seems an approprate use case for withCStringLen, yes, as long as you take care with character encodings: " The translation between Unicode and the encoding of the current locale may be lossy. " So for a "quick hack" withCStringLen is probably the quickest solution, otherwise something that takes into account Unicode and locales etc would be preferable (I think there are some UTF string packages around, maybe on hackage?). for withCStringLen something like this might work (completely untested!): foreign import ccall "function.h function" function_c :: CInt -> Ptr CChar -> CInt -> Ptr CChar -> IO () function :: String -> String -> IO () function s t = withCStringLen s (\(sp,sl) -> withCStringLen t (\(tp,tl) -> function_c (toEnum sl) sp (toEnum tl) tp ) ) -- where toEnum :: Int -> CInt -- perhaps castPtr is useful depending on import declaration too... Hopefully this is in the right direction, > Thanks, > Maur?cio Claude From waldmann at imn.htwk-leipzig.de Sat Nov 8 19:25:32 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Sat Nov 8 19:20:18 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> Message-ID: <49162DFC.2050106@imn.htwk-leipzig.de> > I don't think we > considered the possibility you might use do notation for the list > monad, as it's not an idiom that seems to occur often. depends where you look, I guess. (Such questions could in principle be answered automatically by browsing the code on hackage?) As I said, I am avoiding list comprehensions for purely optical reasons (putting the cart before the horse), so I write "do" in the list monad. Of course I prefer "let" to "where" for the same reasons, so for me you could indeed replace "guard" by "where", and "return" by "select", and "x <- foo" by "from x in foo" and it'd look like the real (linq) thing. - Oh, and replace "Monad" by "Workflow". - Not! NB: Wasn't there a time (before "do") when "list" notation (brackets) would work in any monad? And "map" was a method in "Functor", and we had "class Functor m => Monad m", etc. Well well well times have changed. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081109/973a5e07/signature.bin From nunofaurbiz at yahoo.com Sun Nov 9 00:38:09 2008 From: nunofaurbiz at yahoo.com (Nun Aurbiz) Date: Sun Nov 9 00:32:48 2008 Subject: [Haskell-cafe] FFI documentation? Message-ID: <895610.1902.qm@web57405.mail.re1.yahoo.com> Where do I find the documentation for the FFI for GHC? I've read the FFI report, the GHC user guide and scoured haskell.org but they all gloss over what commands you actually need to give GHC and how to give them. "foreign import blah blah" just gives me undefined references. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081108/dbf62c01/attachment.htm From lrpalmer at gmail.com Sun Nov 9 01:22:43 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun Nov 9 01:17:21 2008 Subject: [Haskell-cafe] FFI documentation? In-Reply-To: <895610.1902.qm@web57405.mail.re1.yahoo.com> References: <895610.1902.qm@web57405.mail.re1.yahoo.com> Message-ID: <7ca3f0160811082222i18d552c7s16109515565aa5e@mail.gmail.com> 2008/11/8 Nun Aurbiz : > Where do I find the documentation for the FFI for GHC? I've read the FFI > report, the GHC user guide and scoured haskell.org but they all gloss over > what commands you actually need to give GHC and how to give them. "foreign > import blah blah" just gives me undefined references. You need to give the libraries you are using on the command line just like gcc. ghc --make Foo -lbar Luke From magnus at therning.org Sun Nov 9 04:07:37 2008 From: magnus at therning.org (Magnus Therning) Date: Sun Nov 9 04:02:25 2008 Subject: [Haskell-cafe] FFI documentation? In-Reply-To: <895610.1902.qm@web57405.mail.re1.yahoo.com> References: <895610.1902.qm@web57405.mail.re1.yahoo.com> Message-ID: <4916A859.8030802@therning.org> Nun Aurbiz wrote: > Where do I find the documentation for the FFI for GHC? I've read the > FFI report, the GHC user guide and scoured haskell.org but they all > gloss over what commands you actually need to give GHC and how to give > them. "foreign import blah blah" just gives me undefined references. I've documented some of manual building in an old post on FFI http://therning.org/magnus/archives/238 Not sure if it's enough to get you on your way though... /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?org http://therning.org/magnus Haskell is an even 'redder' pill than Lisp or Scheme. -- PaulPotts -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081109/951f61d8/signature.bin From batterseapower at hotmail.com Sun Nov 9 05:15:01 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Sun Nov 9 05:09:39 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <49162DFC.2050106@imn.htwk-leipzig.de> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> Message-ID: <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> 2008/11/9 Johannes Waldmann : > NB: Wasn't there a time (before "do") when "list" notation (brackets) > would work in any monad? And "map" was a method in "Functor", > and we had "class Functor m => Monad m", etc. Well well well times have > changed. Sure, I believe the feature was called "monad comprehensions". AFAIK it was removed because it gave confusing error messages to new users of the language (what is this Monad thing? I just want a list of stuff!). List comprehensions really have diverged from being a special "do" notation at the list monad, since you are able to write comprehensions like [(x, y) | x <- xs | y <- ys], and it's not clear how to define "zip" for a monad - but perhaps there is some extension of a monad where it makes sense? All the best, Max From andrewcoppin at btinternet.com Sun Nov 9 05:57:23 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun Nov 9 05:51:57 2008 Subject: [Haskell-cafe] Convolution In-Reply-To: <4914BCFE.5090204@btinternet.com> References: <4914BCFE.5090204@btinternet.com> Message-ID: <4916C213.9040401@btinternet.com> Andrew Coppin wrote: > Assuming DPH ever becomes a reality, how would you implement the above > with it? It seems I'm late to the party - the latest release of GHC claims to include DHP! o_O OTOH, I can't lay my hands on any documentation, so...? (The DPH wiki page was last updated in August 08.) From waldmann at imn.htwk-leipzig.de Sun Nov 9 06:40:02 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Sun Nov 9 06:34:47 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> Message-ID: <4916CC12.8030503@imn.htwk-leipzig.de> > like [(x, y) | x <- xs | y <- ys], and it's not clear how to define > "zip" for a monad - but perhaps there is some extension of a monad > where it makes sense? Well, I question that the above notation makes sense (for lists). It is trying to be too clever. "standard" list comprehensions at least are consistent with mathematical notation for sets. (That is, they are putting the cart before the horse consistently.) But could you show the above code example to some non-ghc-aware person and expect her to guess the meaning correctly? I think not. And even if, the implied zip is dangerous because it does not complain about unequal lengths, and you cannot guess that either. If you write (x,y) <- zip xs ys instead then at least you know that you need to lookup the definition of zip. Best regards, J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081109/368307d6/signature.bin From loup.vaillant at gmail.com Sun Nov 9 07:46:08 2008 From: loup.vaillant at gmail.com (Loup Vaillant) Date: Sun Nov 9 07:40:44 2008 Subject: [Haskell-cafe] Are arbitrary rank types and existentials equivalent? Message-ID: <6f9f8f4a0811090446s40d16dg748a500f4ed91230@mail.gmail.com> Maybe one subsumes the other? What I want to know is if there is an easy way to emulate one with the other, and how much convenience is lost in doing so. For instance, is it possible to implement stream fusion with rank2 types, or the ST monad with existantials? Is there any paper discussing this kind of things? Thanks, Loup From hpacheco at gmail.com Sun Nov 9 07:46:47 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Sun Nov 9 07:41:27 2008 Subject: [Haskell-cafe] Is there a plan for HappS and ghc-6.10.1? Message-ID: <7b92c2840811090446l7b1d46ffl99d65d4ab5cc1c3f@mail.gmail.com> Hi all, The HappS version on Hackage does not yet support ghc 6.10, since GADT pattern matching and the Exception API have changed. One sample error is: src/HAppS/Data/Xml/Base.hs:281:23: GADT pattern match with non-rigid result type `t1' Solution: add a type signature ... Adding a type signature via an auxiliary function instead of a case expression, the problem goes away. readElementRigidity :: (Monad m,Xml t) => Rigidity m -> m ([Element],t) -> Maybe t readElementRigidity Rigid m = ... readElementRigidity Flexible m = ... Is there a plan to update the version on Hackage to support ghc 6.10.1? I don't know either if it may break backwards compatibility. Cheers, hugo -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081109/3c6b2302/attachment.htm From derek.a.elkins at gmail.com Sun Nov 9 13:47:55 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sun Nov 9 13:42:39 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> Message-ID: <1226256475.12919.1.camel@derek-laptop> On Sun, 2008-11-09 at 10:15 +0000, Max Bolingbroke wrote: > 2008/11/9 Johannes Waldmann : > > NB: Wasn't there a time (before "do") when "list" notation (brackets) > > would work in any monad? And "map" was a method in "Functor", > > and we had "class Functor m => Monad m", etc. Well well well times have > > changed. > > Sure, I believe the feature was called "monad comprehensions". AFAIK > it was removed because it gave confusing error messages to new users > of the language (what is this Monad thing? I just want a list of > stuff!). > > List comprehensions really have diverged from being a special "do" > notation at the list monad, since you are able to write comprehensions > like [(x, y) | x <- xs | y <- ys], and it's not clear how to define > "zip" for a monad - but perhaps there is some extension of a monad > where it makes sense? As far as I can tell, no one actually uses parallel list comprehensions. With any luck, the same will be true for generalized list comprehensions. From andrewcoppin at btinternet.com Sun Nov 9 14:18:53 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun Nov 9 14:13:26 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <1226256475.12919.1.camel@derek-laptop> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> Message-ID: <4917379D.2020000@btinternet.com> Derek Elkins wrote: > As far as I can tell, no one actually uses parallel list comprehensions. > With any luck, the same will be true for generalized list > comprehensions. > Generalised? Heck, I don't use list comprehension at all! :-P From dons at galois.com Sun Nov 9 14:58:04 2008 From: dons at galois.com (Don Stewart) Date: Sun Nov 9 14:52:41 2008 Subject: [Haskell-cafe] Is there a plan for HappS and ghc-6.10.1? In-Reply-To: <7b92c2840811090446l7b1d46ffl99d65d4ab5cc1c3f@mail.gmail.com> References: <7b92c2840811090446l7b1d46ffl99d65d4ab5cc1c3f@mail.gmail.com> Message-ID: <20081109195804.GS19817@scytale.galois.com> hpacheco: > Hi all, > The HappS version on Hackage does not yet support ghc 6.10, since GADT > pattern matching and the Exception API have changed. > One sample error is: > src/HAppS/Data/Xml/Base.hs:281:23: > GADT pattern match with non-rigid result type `t1' > Solution: add a type signature > ... > Adding a type signature via an auxiliary function instead of a case > expression, the problem goes away. > readElementRigidity :: (Monad m,Xml t) => Rigidity m -> m ([Element],t) -> > Maybe t > readElementRigidity Rigid m = ... > readElementRigidity Flexible m = ... > Is there a plan to update the version on Hackage to support ghc 6.10.1? > I don't know either if it may break backwards compatibility. Check again. Lemmih updated HAppS to 6.10 today, and already it is in Arch Linux :-) -- Don From hpacheco at gmail.com Sun Nov 9 15:38:14 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Sun Nov 9 15:32:51 2008 Subject: [Haskell-cafe] Is there a plan for HappS and ghc-6.10.1? In-Reply-To: <20081109195804.GS19817@scytale.galois.com> References: <7b92c2840811090446l7b1d46ffl99d65d4ab5cc1c3f@mail.gmail.com> <20081109195804.GS19817@scytale.galois.com> Message-ID: <7b92c2840811091238g20dd50f7n7d64ed443d1935a8@mail.gmail.com> yes, 0.9.3 is out and it has compiled ok.thanks :) hugo On Sun, Nov 9, 2008 at 7:58 PM, Don Stewart wrote: > hpacheco: > > Hi all, > > The HappS version on Hackage does not yet support ghc 6.10, since GADT > > pattern matching and the Exception API have changed. > > One sample error is: > > src/HAppS/Data/Xml/Base.hs:281:23: > > GADT pattern match with non-rigid result type `t1' > > Solution: add a type signature > > ... > > Adding a type signature via an auxiliary function instead of a case > > expression, the problem goes away. > > readElementRigidity :: (Monad m,Xml t) => Rigidity m -> m > ([Element],t) -> > > Maybe t > > readElementRigidity Rigid m = ... > > readElementRigidity Flexible m = ... > > Is there a plan to update the version on Hackage to support ghc > 6.10.1? > > I don't know either if it may break backwards compatibility. > > Check again. Lemmih updated HAppS to 6.10 today, and already it is in > Arch Linux :-) > > -- Don > -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081109/577ed2a8/attachment.htm From hpacheco at gmail.com Sun Nov 9 15:41:12 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Sun Nov 9 15:35:49 2008 Subject: [Haskell-cafe] ANNOUNCE: gitit 0.2 release - wiki using HAppS, git, pandoc In-Reply-To: <20081108203244.GA6568@berkeley.edu> References: <20081108203244.GA6568@berkeley.edu> Message-ID: <7b92c2840811091241r528cbcf8q221092ec61e67b79@mail.gmail.com> a new HAppS version 0.9.3.1 has been released, and gitit requires HApps== 0.9.2.1. should ti be ok just to relax the dependency? On Sat, Nov 8, 2008 at 8:32 PM, John MacFarlane wrote: > I've uploaded an early version of gitit, a Haskell wiki program, to > HackageDB. Gitit uses HAppS as a webserver, git for file storage, > pandoc for rendering the (markdown) pages, and highlighting-kate for > highlighted source code. > > Some nice features of gitit: > > - Pages and uploaded files are stored in a git repository and may > be added, deleted, and modified directly using git. > - Pages may be organized into subdirectories. > - Pandoc's extended version of markdown is used, so you can do tables, > footnotes, syntax-highlighted code blocks, and LaTeX math. (And > you can you pandoc to convert pages into many other formats.) > - Math is rendered using jsMath (which must be installed > separately). > - Source code files in the repository are automatically rendered with > syntax highlighting (plain/text version is also available). > > You can check it out on my webserver: http://johnmacfarlane.net:5001/ > Or try it locally: > > cabal update > cabal install pandoc -fhighlighting > cabal install gitit > gitit # note: this will create two subdirectories in the working > directory > # then browse to http://localhost:5001. > > There's a git repository at http://github.com/jgm/gitit/tree/master. > Comments and patches are welcome. > > John > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081109/ec602bc7/attachment.htm From dons at galois.com Sun Nov 9 15:49:45 2008 From: dons at galois.com (Don Stewart) Date: Sun Nov 9 15:44:22 2008 Subject: [Haskell-cafe] ANNOUNCE: gitit 0.2 release - wiki using HAppS, git, pandoc In-Reply-To: <7b92c2840811091241r528cbcf8q221092ec61e67b79@mail.gmail.com> References: <20081108203244.GA6568@berkeley.edu> <7b92c2840811091241r528cbcf8q221092ec61e67b79@mail.gmail.com> Message-ID: <20081109204945.GY19817@scytale.galois.com> hpacheco: > a new HAppS version [1]0.9.3.1 has been released, and gitit requires > HApps==[2]0.9.2.1. should ti be ok just to relax the dependency? Seems like 0.9.x series should be ok. -- Don From gale at sefer.org Sun Nov 9 16:01:28 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sun Nov 9 15:56:05 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <1226256475.12919.1.camel@derek-laptop> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> Message-ID: <2608b8a80811091301r4351b8a6x8762c637c60457f3@mail.gmail.com> Derek Elkins wrote: > As far as I can tell, no one actually uses parallel list comprehensions. > With any luck, the same will be true for generalized list > comprehensions. I second this. -Yitz From roma at ro-che.info Sun Nov 9 16:34:37 2008 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun Nov 9 16:29:20 2008 Subject: [Haskell-cafe] Physics engines purely in Haskell? In-Reply-To: <4916261B.6050806@bigpond.net.au> References: <4916261B.6050806@bigpond.net.au> Message-ID: <20081109213437.GA5635@flit> * Mark Wassell [2008-11-09 10:51:55+1100] > Has anyone thought about or embarked on the task of developing a 2D or > 3D physics engine purely in Haskell? > > There is Hipmunk but I'm wondering about a purely Haskell > implementation; possibly a port of Chipmunk to Haskell. As Don said, there is a physics engine called Hpysics. There are still some issues to be solved, but if you're interested in using it, please drop me a line! -- Roman I. Cheplyaka :: http://ro-che.info/ kzm: My program contains a bug. How ungrateful, after all I've done for it. From jgm at berkeley.edu Sun Nov 9 16:41:00 2008 From: jgm at berkeley.edu (John MacFarlane) Date: Sun Nov 9 16:35:38 2008 Subject: [Haskell-cafe] Re: ANNOUNCE: gitit 0.2 release - wiki using HAppS, git, pandoc In-Reply-To: <7b92c2840811091241r528cbcf8q221092ec61e67b79@mail.gmail.com> References: <20081108203244.GA6568@berkeley.edu> <7b92c2840811091241r528cbcf8q221092ec61e67b79@mail.gmail.com> Message-ID: <20081109214059.GA13552@berkeley.edu> I've just uploaded a new version (0.2.1) that requires HAppS >= 0.9.3 && < 0.9.4. (There are small API changes from 0.9.2 to 0.9.3, so I thought it best not to allow 0.9.2.x, even though it still compiles with a warning.) +++ Hugo Pacheco [Nov 09 08 20:41 ]: > a new HAppS version [1]0.9.3.1 has been released, and gitit requires > HApps==[2]0.9.2.1. should ti be ok just to relax the dependency? > > On Sat, Nov 8, 2008 at 8:32 PM, John MacFarlane <[3]jgm@berkeley.edu> > wrote: > > I've uploaded an early version of gitit, a Haskell wiki program, to > HackageDB. Gitit uses HAppS as a webserver, git for file storage, > pandoc for rendering the (markdown) pages, and highlighting-kate for > highlighted source code. > > Some nice features of gitit: > > - Pages and uploaded files are stored in a git repository and may > be added, deleted, and modified directly using git. > - Pages may be organized into subdirectories. > - Pandoc's extended version of markdown is used, so you can do tables, > footnotes, syntax-highlighted code blocks, and LaTeX math. (And > you can you pandoc to convert pages into many other formats.) > - Math is rendered using jsMath (which must be installed > separately). > - Source code files in the repository are automatically rendered with > syntax highlighting (plain/text version is also available). > > You can check it out on my webserver: [4]http://johnmacfarlane.net:5001/ > Or try it locally: > > cabal update > cabal install pandoc -fhighlighting > cabal install gitit > gitit # note: this will create two subdirectories in the working > directory > # then browse to [5]http://localhost:5001. > > There's a git repository at [6]http://github.com/jgm/gitit/tree/master. > Comments and patches are welcome. > > John > _______________________________________________ > Haskell-Cafe mailing list > [7]Haskell-Cafe@haskell.org > [8]http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- > [9]www.di.uminho.pt/~hpacheco > > References > > Visible links > 1. http://0.9.3.1/ > 2. http://0.9.2.1/ > 3. mailto:jgm@berkeley.edu > 4. http://johnmacfarlane.net:5001/ > 5. http://localhost:5001/ > 6. http://github.com/jgm/gitit/tree/master > 7. mailto:Haskell-Cafe@haskell.org > 8. http://www.haskell.org/mailman/listinfo/haskell-cafe > 9. http://www.di.uminho.pt/~hpacheco > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From conal at conal.net Sun Nov 9 16:59:40 2008 From: conal at conal.net (Conal Elliott) Date: Sun Nov 9 16:54:17 2008 Subject: [Haskell-cafe] Announce: Reactive library (FRP) and mailing list Message-ID: Reactive [1] is a library for functional reactive programming (FRP), similar to the original Fran [2] but with a more modern interface (using standard type classes) and a hybrid push/pull implementation. It is designed to be used in a variety of contexts, such as interactive 2D and 3D graphics, graphical user interfaces, web services, and automatic recompilation/re-execution. It has a simple and precise semantics based on continuous time and is built on a notion of functional future values. The semantics and implementation are described in the paper "Simply efficient functional reactivity" [3]. Reactive now has a mailing list [4] and a feature/bug tracker [5]. [1] http://haskell.org/haskellwiki/Reactive [2] http://conal.net/Fran [3] http://conal.net/papers/simply-reactive [4] http://www.haskell.org/mailman/listinfo/reactive [5] http://trac.haskell.org/reactive -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081109/856c428c/attachment.htm From chris at eidhof.nl Sun Nov 9 17:01:41 2008 From: chris at eidhof.nl (Chris Eidhof) Date: Sun Nov 9 16:56:19 2008 Subject: [Haskell-cafe] Re: ANNOUNCE: gitit 0.2 release - wiki using HAppS, git, pandoc In-Reply-To: <20081109214059.GA13552@berkeley.edu> References: <20081108203244.GA6568@berkeley.edu> <7b92c2840811091241r528cbcf8q221092ec61e67b79@mail.gmail.com> <20081109214059.GA13552@berkeley.edu> Message-ID: <37F163D2-8528-416B-84BF-DAFFC9FF5E77@eidhof.nl> If anyone else has problems installing gitit, try updating your cabal- install (and cabal). I had "old" versions on my computer, and updating them solved my gitit build-problems. -chris On 9 nov 2008, at 22:41, John MacFarlane wrote: > I've just uploaded a new version (0.2.1) that requires HAppS >= > 0.9.3 && > < 0.9.4. (There are small API changes from 0.9.2 to 0.9.3, so I > thought > it best not to allow 0.9.2.x, even though it still compiles with a > warning.) > > +++ Hugo Pacheco [Nov 09 08 20:41 ]: >> a new HAppS version [1]0.9.3.1 has been released, and gitit >> requires >> HApps==[2]0.9.2.1. should ti be ok just to relax the dependency? >> >> On Sat, Nov 8, 2008 at 8:32 PM, John MacFarlane <[3]jgm@berkeley.edu >> > >> wrote: >> >> I've uploaded an early version of gitit, a Haskell wiki >> program, to >> HackageDB. Gitit uses HAppS as a webserver, git for file storage, >> pandoc for rendering the (markdown) pages, and highlighting- >> kate for >> highlighted source code. >> >> Some nice features of gitit: >> >> - Pages and uploaded files are stored in a git repository and >> may >> be added, deleted, and modified directly using git. >> - Pages may be organized into subdirectories. >> - Pandoc's extended version of markdown is used, so you can do >> tables, >> footnotes, syntax-highlighted code blocks, and LaTeX math. >> (And >> you can you pandoc to convert pages into many other formats.) >> - Math is rendered using jsMath (which must be installed >> separately). >> - Source code files in the repository are automatically >> rendered with >> syntax highlighting (plain/text version is also available). >> >> You can check it out on my webserver: [4]http://johnmacfarlane.net:5001/ >> Or try it locally: >> >> cabal update >> cabal install pandoc -fhighlighting >> cabal install gitit >> gitit # note: this will create two subdirectories in the >> working >> directory >> # then browse to [5]http://localhost:5001. >> >> There's a git repository at [6]http://github.com/jgm/gitit/tree/master >> . >> Comments and patches are welcome. >> >> John >> _______________________________________________ >> Haskell-Cafe mailing list >> [7]Haskell-Cafe@haskell.org >> [8]http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> -- >> [9]www.di.uminho.pt/~hpacheco >> >> References >> >> Visible links >> 1. http://0.9.3.1/ >> 2. http://0.9.2.1/ >> 3. mailto:jgm@berkeley.edu >> 4. http://johnmacfarlane.net:5001/ >> 5. http://localhost:5001/ >> 6. http://github.com/jgm/gitit/tree/master >> 7. mailto:Haskell-Cafe@haskell.org >> 8. http://www.haskell.org/mailman/listinfo/haskell-cafe >> 9. http://www.di.uminho.pt/~hpacheco > >> _______________________________________________ >> 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 derek.a.elkins at gmail.com Sun Nov 9 17:02:36 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sun Nov 9 16:57:19 2008 Subject: [Haskell-cafe] Are arbitrary rank types and existentials equivalent? In-Reply-To: <6f9f8f4a0811090446s40d16dg748a500f4ed91230@mail.gmail.com> References: <6f9f8f4a0811090446s40d16dg748a500f4ed91230@mail.gmail.com> Message-ID: <1226268156.12919.10.camel@derek-laptop> On Sun, 2008-11-09 at 13:46 +0100, Loup Vaillant wrote: > Maybe one subsumes the other? > > What I want to know is if there is an easy way to emulate one with the > other, and how much convenience is lost in doing so. > > For instance, is it possible to implement stream fusion with rank2 > types, or the ST monad with existantials? > > Is there any paper discussing this kind of things? exists a. F a ~ forall r. (forall a. F a -> r) -> r runST :: exist s. ST s a -> a -- this type is implied by runST's but does not imply runST's so it is less general There are various rules for moving quantifiers around. Any text on intuitionistic predicate logic should list the rules. However, this is replacing existentials with higher rank uses of universals. Higher rank types applies to any quantifier, and so to attempt to replace higher rank uses of universals would require higher rank uses of existentials in general. From dons at galois.com Sun Nov 9 17:02:47 2008 From: dons at galois.com (Don Stewart) Date: Sun Nov 9 16:57:29 2008 Subject: [Haskell-cafe] Re: [Haskell] Announce: Reactive library (FRP) and mailing list In-Reply-To: References: Message-ID: <20081109220247.GM19817@scytale.galois.com> conal: > Reactive [1] is a library for functional reactive programming (FRP), > similar to the original Fran [2] but with a more modern interface (using > standard type classes) and a hybrid push/pull implementation. It is > designed to be used in a variety of contexts, such as interactive 2D and > 3D graphics, graphical user interfaces, web services, and automatic > recompilation/re-execution. It has a simple and precise semantics based > on continuous time and is built on a notion of functional future values. > The semantics and implementation are described in the paper "Simply > efficient functional reactivity" [3]. > > Reactive now has a mailing list [4] and a feature/bug tracker [5]. And now available for Arch Linux, http://aur.archlinux.org/packages.php?ID=17854 From conal at conal.net Sun Nov 9 17:03:51 2008 From: conal at conal.net (Conal Elliott) Date: Sun Nov 9 16:58:27 2008 Subject: [Haskell-cafe] Announce: FieldTrip library (functional 3D) and mailing list Message-ID: FieldTrip [1] is a library for functional 3D graphics. It is intended for building static, animated, and interactive 3D geometry, efficient enough for real-time synthesis and display. Since FieldTrip is functional, one describes what models are, not how to render them (being rather than doing). Surfaces are described as functions from 2D space to 3D space. As such, they are intrinsically curved rather than faceted. Surface rendering tessellates adaptively, caching tessellations in an efficient, infinite data structure (from the MemoTrie library) for reuse. Surface normals are computed automatically and exactly, using the derivative tools in the vector-space library. For animation or interaction, FieldTrip can be used with the Reactive [2] library for functional reactive programming (and possibly other animation frameworks). By design, FieldTrip is completely orthogonal to any formulation or implementation of FRP. The reactive-fieldtrip [3] library links Reactive and FieldTrip. FieldTrip now has a mailing list [4] and a feature/bug tracker [5]. [1] http://haskell.org/haskellwiki/FieldTrip [2] http://haskell.org/haskellwiki/reactive [3] http://haskell.org/haskellwiki/reactive-fieldtrip [4] http://www.haskell.org/mailman/listinfo/FieldTrip [5] http://trac.haskell.org/FieldTrip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081109/eadc6291/attachment.htm From ryani.spam at gmail.com Sun Nov 9 17:22:20 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sun Nov 9 17:16:57 2008 Subject: [Haskell-cafe] Are arbitrary rank types and existentials equivalent? In-Reply-To: <6f9f8f4a0811090446s40d16dg748a500f4ed91230@mail.gmail.com> References: <6f9f8f4a0811090446s40d16dg748a500f4ed91230@mail.gmail.com> Message-ID: <2f9b2d30811091422r342c92f6iceb9996a6aedd4a@mail.gmail.com> There's a natural relation between higher rank types and existentials; one way to think about it is this: if you have some existential type t (subject to some constraints), you cannot operate on it except with some function that accepts any type t subject to those constraints. There is a simple encoding of existential types using higher rank types: Given > data E a1..an = forall e1...en. (constraints) => E t1..tn where t1..tn are types in terms of a1..an, we replace with > data E' a1..an = E' (forall b. (forall e1..en. t1 -> t2 -> ... -> tn -> b) -> b) Any function f that pattern matches on E can use E' instead in the following way: > f (E v1..vn) = exp becomes > f (E' exist) = exist f' where > f' v1..vn = exp An example: > data HasShow = forall a. Show a => HasShow a > data HasShow' = HasShow' (forall b. (forall a. Show a => (a -> b)) -> b) > useShow :: HasShow -> String > useShow (HasShow x) = show x > useShow' :: HasShow' -> String > useShow' (HasShow' f) = f (\x -> show x) I don't think there is much a link between fusion and the type system; stream fusion is a compilation technology, like inlining. To demonstrate, here's a simple fusion engine using this encoding: > {-# LANGUAGE RankNTypes #-} > module Fusion where > data StreamR s a = Done | Skip s | Yield a s > newtype Stream a = Stream (forall b. (forall s. s -> (s -> StreamR s a) -> b) -> b) > stream :: [a] -> Stream a > stream xs = Stream (\f -> f xs go) where > go [] = Done > go (x:xs) = Yield x xs > {-# NOINLINE[1] stream #-} > unstream :: Stream a -> [a] > unstream (Stream k) = k loop where > loop s next = case (next s) of > Done -> [] > Skip s' -> loop s' next > Yield a s' -> a : loop s' next > {-# NOINLINE[1] unstream #-} You then end up with the same (stream (unstream s) = s) rule: > {-# RULES "stream/unstream" forall s. stream (unstream s) = s #-} Now lets implement a stream version of map: > mapS f = unstream . mapStream f . stream > mapStream :: (a -> b) -> Stream a -> Stream b > mapStream f (Stream k) = k mapStream' where > mapStream' s0 next = Stream (\g -> g s0 go) where > go s = case next s of > Done -> Done > Skip s' -> Skip s' > Yield a s' -> Yield (f a) s' > test :: [Int] -> [Int] > test = mapS (+1) . mapS (*2) Looking at the core generated for "test", we see that the loops are indeed fused: (case x_ag7 of wild1_anS { GHC.Types.I# x1_anU -> GHC.Types.I# (GHC.Prim.+# (GHC.Prim.*# x1_anU 2) 1) }) (which basically says "x_ag7 * 2 + 1") I don't think there is an encoding that goes from higher rank types to existentials, however. Existentials lose information which cannot be recovered. I can't think of a way to use existentials to encode, for example, natural transformations on functors, while maintaining that the type "inside" the functor remains the same. Here's some code to make this idea concrete: > type Trans f g = (forall a. f a -> g a) > compose :: Trans g h -> Trans f g -> Trans f h > compose g2h f2g = \fa -> g2h (f2g fa) You can represent a "lossy" transformation between functors as: > data Any f = forall a. Any (f a) > type LossyTrans f g = Any f -> Any g But then there is no way to know that the "a" held in the "Any f" matches the "a" in the "Any g". From loup.vaillant at gmail.com Sun Nov 9 18:04:27 2008 From: loup.vaillant at gmail.com (Loup Vaillant) Date: Sun Nov 9 17:59:03 2008 Subject: [Haskell-cafe] Are arbitrary rank types and existentials equivalent? In-Reply-To: <2f9b2d30811091422r342c92f6iceb9996a6aedd4a@mail.gmail.com> References: <6f9f8f4a0811090446s40d16dg748a500f4ed91230@mail.gmail.com> <2f9b2d30811091422r342c92f6iceb9996a6aedd4a@mail.gmail.com> Message-ID: <6f9f8f4a0811091504n2a2b4628t70b4748c3d17e07f@mail.gmail.com> Thank you, everyone. You have addressed my concerns very accurately. So in short, higer rank types subsume existentials. Good. And the burden of emulating existentials can be lowered by a suitable macro system. Very good. 2008/11/9 Derek Elkins : > There are various rules for moving quantifiers around. Any text on > intuitionistic predicate logic should list the rules. Err, where can I find such texts? I don't even understand "intuitionistic predicate logic" :-( Cheers, Loup From simon.clarkstone at gmail.com Sun Nov 9 19:24:37 2008 From: simon.clarkstone at gmail.com (Simon Richard Clarkstone) Date: Sun Nov 9 19:19:19 2008 Subject: [Haskell-cafe] foldl vs foldl' In-Reply-To: References: Message-ID: <49177F45.9070102@gmail.com> Bas van Dijk wrote: > On Wed, Nov 5, 2008 at 12:43 AM, Bas van Dijk wrote: >> 2008/11/5 Daryoush Mehrtash : >>> Are there cases (function or list) where the result of foldl (or foldr)would >>> be different that foldl' (or foldr')? >> Maybe this wiki article I wrote some time ago will answer your question: >> >> http://haskell.org/haskellwiki/Foldr_Foldl_Foldl' > > Oops that link should be: > > http://haskell.org/haskellwiki/Foldr_Foldl_Foldl%27 I have an idea for the foldl diagram. If you rotate the RHS 90deg clockwise, it slopes the same way as the original list, but the 'f's are still rotated sideways to signify which their inputs are. That makes the relationship between imperative accumulator loops and foldl a bit clearer to me, as well as the relationship between the list and the recursion structure. -- src/ From cppljevans at suddenlink.net Sun Nov 9 20:48:47 2008 From: cppljevans at suddenlink.net (Larry Evans) Date: Sun Nov 9 19:38:32 2008 Subject: [Haskell-cafe] Re: Are arbitrary rank types and existentials equivalent? In-Reply-To: <6f9f8f4a0811091504n2a2b4628t70b4748c3d17e07f@mail.gmail.com> References: <6f9f8f4a0811090446s40d16dg748a500f4ed91230@mail.gmail.com> <2f9b2d30811091422r342c92f6iceb9996a6aedd4a@mail.gmail.com> <6f9f8f4a0811091504n2a2b4628t70b4748c3d17e07f@mail.gmail.com> Message-ID: On 11/09/08 17:04, Loup Vaillant wrote: [snip] > Err, where can I find such texts? I don't even understand > "intuitionistic predicate logic" :-( I just googled that phrase and got many hits. I think metaprl implements something like that: http://metaprl.org/default.html I've often wondered about haskell and metaprl. I know metprl has something like a hierarchy of types and that's used to avoid Russell's paradox. I also remember reading somewhere (can't remember where) that there was something in category theory that had a hierarchy of categories. Maybe someone else can provide more details. From korcan_h at hotmail.com Sun Nov 9 23:13:24 2008 From: korcan_h at hotmail.com (Korcan Hussein) Date: Sun Nov 9 23:08:00 2008 Subject: [Haskell-cafe] A video of Frag Message-ID: I don't understand why there is no video of Frag online so I made one here: http://uk.youtube.com/watch?v=0jYdu2u8gAU _________________________________________________________________ BigSnapSearch.com - 24 prizes a day, every day - Search Now! http://clk.atdmt.com/UKM/go/117442309/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081110/1eecef9c/attachment.htm From dons at galois.com Sun Nov 9 23:16:34 2008 From: dons at galois.com (Don Stewart) Date: Sun Nov 9 23:11:10 2008 Subject: [Haskell-cafe] A video of Frag In-Reply-To: References: Message-ID: <20081110041634.GA21892@scytale.galois.com> korcan_h: > I don't understand why there is no video of Frag online so I made one > here: http://uk.youtube.com/watch?v=0jYdu2u8gAU Thanks! I've linked to the video on Frag's homepage, http://haskell.org/haskellwiki/Frag -- Don From kyagrd at gmail.com Mon Nov 10 00:16:09 2008 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Mon Nov 10 00:10:35 2008 Subject: [Haskell-cafe] How to getCh on MS Windows command line? Message-ID: What I mean by getCh is the non-buffered non-echoed version of getChar, which Hugs used to provided as an extension but not any more. Is there any way to have a non-buffered non-echoed single character input function on MS Windows command line using only the libraries in the MS Windows distribution packages of either GHC or Hugs? The reason to why this is important for me is because I am translating Graham Hutton's "Programming in Haskell" into Korean (soon to be published), which illustrates interactive programming with the example of a calculator that responds instantly for every keystroke of numbers and arithmetic operations running on text mode. It is very important to consider the readers who only have access to MS Windows systems, because Korean OS market share is completely skewed towards MS Windows for very embarrassing reasons that I do not even want to mention. And, isn't GHC developed in MSR anyway? :-) I remember that this is an old problem for both of the two most widely used Haskell implementation, Hugs and GHC. In ghc 6.8 getChar had a bit strange behavior. As far as I remember it always worked as if it were NoBuffering. Fortunately, in the recently released ghc 6.10, this has been fixed. We now actually have to set the buffering mode to NoBuffering with hSetBufferring to get the non-buffered behavior of getChar. But, it still isn't working on MS Windows. In Hugs, hSetBuffering neither works on Unix terminal nor on MS Windows command line. Surprisingly, it works in WinHugs. However, I cannot use WinHugs for my purpose because the interactive calculator example in the book also uses beep characters and ANSI codes which do not work in WinHugs. Thanks for any hacks or suggestions, -- Ahn, Ki Yung From bulat.ziganshin at gmail.com Mon Nov 10 01:55:42 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Nov 10 01:50:41 2008 Subject: [Haskell-cafe] How to getCh on MS Windows command line? In-Reply-To: References: Message-ID: <1726166656.20081110095542@gmail.com> ??o ?, ???, ???? ?, ??, ???9 ?, ?u ??? > ?? I ?? ? ??h ? ?e ?????? ????? ???n ? ???? > ??h ?? ?? ? ???? ? ? ????n ?t ?t ?y ??. ? ??s ?r ? ? ?? ??????r = ??M ??.????) ???h ???n ??? ??l ??? ???.h ??? ???h ? IO ?? ? ???????? ??n ?????g ?t ??? ? ?e ????. i ????? ???? ?? i ?d ??? ?u ?? ?? ?? ???? ? ?s ?? ?? ?? ???? ?t i ??t ???r ???s ? ??e ?? ?'s ?t ?? ?? ? ???l ?? ??? ???, ?t ?????? ??x ??e ?d ???l ??/?c ??e -- ?? ???? ??t ??????.?????????m From waldmann at imn.htwk-leipzig.de Mon Nov 10 03:09:33 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Nov 10 03:04:22 2008 Subject: [Haskell-cafe] Re: generalized list comprehensions References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> <2608b8a80811091301r4351b8a6x8762c637c60457f3@mail.gmail.com> Message-ID: Well, my original post wasn't that negative ... Indeed "then f [by e]" seems a nice idea *but* the point was that I'd like to have this in any monad. The type of f in "then f" should be m a -> m b, not just m a -> m a, because then you don't need special syntax for "group", which is somewhat like [a] -> [[a]] ? J.W. From hpacheco at gmail.com Mon Nov 10 04:15:14 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Mon Nov 10 04:09:53 2008 Subject: [Haskell-cafe] A video of Frag In-Reply-To: References: Message-ID: <7b92c2840811100115n4e53e7f3tcecaea2c5acc059a@mail.gmail.com> I read on your youtube post that you are planning to write a build-it-yourself tutorial.Perhaps this effort could be targeted at creating a cabal package in Hackage (I do not know the implications of that, just speaking out loud). Cheers, hugo 2008/11/10 Korcan Hussein > I don't understand why there is no video of Frag online so I made one > here: http://uk.youtube.com/watch?v=0jYdu2u8gAU > > ------------------------------ > Click here for FREE customisable desktop wallpapers. Get them Now! > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081110/a8b7e17d/attachment-0001.htm From batterseapower at hotmail.com Mon Nov 10 05:59:56 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Mon Nov 10 05:54:31 2008 Subject: [Haskell-cafe] Re: generalized list comprehensions In-Reply-To: References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> <2608b8a80811091301r4351b8a6x8762c637c60457f3@mail.gmail.com> Message-ID: <9d4d38820811100259v4ae58aa2j37447bf23ba5cb79@mail.gmail.com> 2008/11/10 Johannes Waldmann : > Well, my original post wasn't that negative ... > > Indeed "then f [by e]" seems a nice idea *but* > the point was that I'd like to have this in any monad. > > The type of f in "then f" should be m a -> m b, not just m a -> m a, > because then you don't need special syntax for "group", > which is somewhat like [a] -> [[a]] ? Hi Johannes, I'm not sure what it would mean for f to have type m a -> m b. The point of the parametric polymorphism in the type forall a. m a -> m b is that the "f" function is guarenteed not to inspect the structure of the (list/monad) element. This allows the compiler to choose a representation for the intermediate tuples used in the desugaring freely. The "group" syntax really does desugar differently from "then" because the compiler inserts an extra unzip_n that the user could not have written, given that parametric polymorphism. All the best, Max From kowey at darcs.net Mon Nov 10 07:10:18 2008 From: kowey at darcs.net (Eric Kow) Date: Mon Nov 10 07:04:57 2008 Subject: [Haskell-cafe] announcing darcs 2.1.1rc2 Message-ID: <20081110121018.GG9514@Macintosh.local> Hi everybody, The release candidate for darcs 2.1.1 is now available at http://darcs.net/darcs-2.1.1rc2.tar.gz This release is very much intended to be darcs 2.1.0 plus GHC 6.10.1 support. We have also thrown in some simplifications to the regression testing suite and a Windows bugfix (which we pulled in because of a dependency and retained because it was a small and useful). Please give this a try, especially those of you on GHC 6.10 or Windows, and let us know how things work out. Because we have only selected a very small subset of changes to include (using darcs's cherry-picking abilities, of course!), I am confident that we can get by on a reduced release cycle. If all goes well, the official release date for darcs 2.1.1 will be 2008-11-17. Thanks! Eric darcs (2.1.1rc2) * Portability: Removed accidental QuickCheck 2.1 configure check. Note that it may be required in a future version of darcs. -- Eric Kow Mon, 10 Nov 2008 11:17:00 GMT darcs (2.1.1rc1) * Portability: GHC 6.10.1 support (Petr Ro?kai, Eric Kow) * Bug Fix: Fix file handle leak and check for exceptions on process running on Windows (issue784, Salvatore Insalaco) * Quality Assurance: Consolidated regression test suites using shell scripts only (Eric Kow, Tommy Petterson, Matthias Kilian) -- Eric Kow Mon, 10 Nov 2008 09:49:00 GMT -- Eric Kow PGP Key ID: 08AC04F9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081110/f64d20c2/attachment.bin From alexey.skladnoy at gmail.com Mon Nov 10 08:02:56 2008 From: alexey.skladnoy at gmail.com (Alexey Khudyakov) Date: Mon Nov 10 07:57:30 2008 Subject: [Haskell-cafe] Histogram creation Message-ID: <8425cc0e0811100502u54fad0b5y14380ce589c5fb1a@mail.gmail.com> Hello! I'm tryig to write efficient code for creating histograms. I have following requirements for it: 1. O(1) element insertion 2. No reallocations. Thus in place updates are needed. accumArray won't go because I need to fill a lot of histograms (hundrends) from vely long list of data (possibly millions of elements) and it will traverse input data for each histogram. It seems that I need to use mutable array and/or ST monad or something else. Sadly both of them are tricky and difficult to understand. So good examples or any other ideas greatly appreciated. -- Alexey Khudyakov From bit at mutantlemon.com Mon Nov 10 08:05:23 2008 From: bit at mutantlemon.com (Bit Connor) Date: Mon Nov 10 07:59:58 2008 Subject: [Haskell-cafe] Trouble installing ghc-6.10.1 on linux Message-ID: <6205bd290811100505o4be9248pfe0b70a106692ec2@mail.gmail.com> I'm trying to install ghc 6.10.1 on a machine with the crux distro. libc version 2.3.6 gcc 4.0.3 linux version 2.6.15.6 First I tried the binary version ghc-6.10.1-i386-unknown-linux.tar.bz2 and I very quickly get this error: $ ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu Which we'll further canonicalise into: i386-unknown-linux checking for path to top of build tree... configure: error: cannot determine current directory $ Next I tried building the source version ghc-6.10.1-src.tar.bz2 using ghc 6.6 that is already installed. configure works but make eventually dies with: ... Configuring ghc-6.10.1... cabal-bin: At least the following dependencies are missing: Cabal -any, base <3, filepath >=1 && <1.2, haskell98 -any, hpc -any, template-haskell -any, unix -any make[2]: *** [boot.stage.2] Error 1 Any ideas? Thanks, Bit From jake at pikewerks.com Mon Nov 10 09:22:20 2008 From: jake at pikewerks.com (Jake Mcarthur) Date: Mon Nov 10 09:16:57 2008 Subject: [Haskell-cafe] A video of Frag In-Reply-To: <7b92c2840811100115n4e53e7f3tcecaea2c5acc059a@mail.gmail.com> References: <7b92c2840811100115n4e53e7f3tcecaea2c5acc059a@mail.gmail.com> Message-ID: <7F7CDDDB-EE95-4891-96A8-15DC8174194C@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 10, 2008, at 3:15 AM, Hugo Pacheco wrote: > Perhaps this effort could be targeted at creating a cabal package in > Hackage It's already there. :) http://hackage.haskell.org/cgi-bin/hackage-scripts/package/frag - - Jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkYQ5wACgkQye5hVyvIUKkZCACgwy3VdzBfVTf8aIKxk67PAzgt yyEAnjrbiaZTBQFqfI3jUSEn96Iv16GP =Jwyf -----END PGP SIGNATURE----- From hpacheco at gmail.com Mon Nov 10 10:42:11 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Mon Nov 10 10:36:45 2008 Subject: [Haskell-cafe] A video of Frag In-Reply-To: <7b92c2840811100545m2ad9a186j99ff1d1e774e8e58@mail.gmail.com> References: <7b92c2840811100115n4e53e7f3tcecaea2c5acc059a@mail.gmail.com> <7b92c2840811100246r1abb5cc2pd565cab5e3b28fd9@mail.gmail.com> <7b92c2840811100545m2ad9a186j99ff1d1e774e8e58@mail.gmail.com> Message-ID: <7b92c2840811100742l41d71928lfc402dfaeb52263f@mail.gmail.com> Yes, I installed it via cabal-install.I am using GHC 6.10.1 now, but it had > the same results in 6.6 (if I remember well) before. It may be a Mac issue. > > On Mon, Nov 10, 2008 at 1:39 PM, Korcan Hussein wrote: > >> Sorry I have no idea, which version of GHC are you using? did you try >> using cabal-install? ( >> http://hackage.haskell.org/trac/hackage/wiki/CabalInstall) >> >> ------------------------------ >> Date: Mon, 10 Nov 2008 10:46:45 +0000 >> >> From: hpacheco@gmail.com >> To: korcan_h@hotmail.com >> Subject: Re: [Haskell-cafe] A video of Frag >> >> Oh, sorry I haven't noticed.Trying to compile in my OS X machine, all >> compiles ok via cabal, but then I get >> >> $ ./frag ../share/frag-1.1.2/leveleg >> Bus error >> >> I remember compiling frag 1/2 years ago and getting the same result. >> It is not windows, but do you have any hint? >> >> On Mon, Nov 10, 2008 at 10:12 AM, Korcan Hussein wrote: >> >> Actually such a package already exists, it's quite a simple procedure as >> long as you have the right tools and and setup but for windows platform >> this information is a bit scattered/dispersed and there is no central >> information about getting such a thing up and running from complete scratch. >> This is what i'm referring to in my comment. >> >> ------------------------------ >> Date: Mon, 10 Nov 2008 09:15:14 +0000 >> From: hpacheco@gmail.com >> To: korcan_h@hotmail.com >> Subject: Re: [Haskell-cafe] A video of Frag >> CC: haskell-cafe@haskell.org >> >> >> I read on your youtube post that you are planning to write a >> build-it-yourself tutorial. Perhaps this effort could be targeted at >> creating a cabal package in Hackage (I do not know the implications of that, >> just speaking out loud). >> >> Cheers, >> hugo >> >> 2008/11/10 Korcan Hussein >> >> I don't understand why there is no video of Frag online so I made one >> here: http://uk.youtube.com/watch?v=0jYdu2u8gAU >> >> ------------------------------ >> Click here for FREE customisable desktop wallpapers. Get them Now! >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >> >> >> -- >> www.di.uminho.pt/~hpacheco >> >> ------------------------------ >> Click here for FREE customisable desktop wallpapers. Get them Now! >> >> >> >> >> -- >> www.di.uminho.pt/~hpacheco >> >> ------------------------------ >> Get the best wallpapers on the Web - FREE. Click here! >> > > > > -- > www.di.uminho.pt/~hpacheco > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081110/504c919e/attachment.htm From duncan.coutts at worc.ox.ac.uk Mon Nov 10 11:04:42 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Nov 10 10:59:19 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <4917379D.2020000@btinternet.com> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> <4917379D.2020000@btinternet.com> Message-ID: <1226333082.17214.36.camel@localhost> On Sun, 2008-11-09 at 19:18 +0000, Andrew Coppin wrote: > Derek Elkins wrote: > > As far as I can tell, no one actually uses parallel list comprehensions. > > With any luck, the same will be true for generalized list > > comprehensions. > > > > Generalised? Heck, I don't use list comprehension at all! :-P Perhaps you should! :-) When I first started with Haskell I kind of had the idea that list comprehensions were just for beginners and that 'real' hackers used just concatMaps and filters. A couple years later I 'rediscovered' list comprehensions and I now use them frequently. There are many cases in real programs where simple and not-so-simple list comprehensions are the clearest way of expressing the solution. In particular the easy support for refutable pattern matching in the generators allows some succinct and clear code. Just a random example out of Cabal: warn verbosity $ "This package indirectly depends on multiple versions of the same " ++ "package. This is highly likely to cause a compile failure.\n" ++ unlines [ "package " ++ display pkg ++ " requires " ++ display (PackageIdentifier name ver) | (name, uses) <- inconsistencies , (pkg, ver) <- uses ] Pretty concise and clear I think. Duncan From neil.mitchell.2 at credit-suisse.com Mon Nov 10 11:14:35 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Mon Nov 10 11:10:28 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <1226333082.17214.36.camel@localhost> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> <4917379D.2020000@btinternet.com> <1226333082.17214.36.camel@localhost> Message-ID: > > Generalised? Heck, I don't use list comprehension at all! :-P > > Perhaps you should! :-) You definitely should! Take a look at the Uniplate paper for some wonderful concise uses of list comprehensions for abstract syntax tree traversals. If you use a language like F# they become even more common - due to a clunkier syntax for lambdas, less library functions and no operator sections. In my F# I rarely use a map at all. But my faviourite list comprehension trick was shown to me by Colin Runciman: prettyPrint b (lhs :+: rhs) = ['('|b] ++ f lhs ++ " + " ++ f rhs ++ [')'|b] Imagine b represents whether something should be bracketed or not. In general: if boolean then [value] else [] Can be written as: [value | boolean] Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From briqueabraque at yahoo.com Mon Nov 10 11:59:06 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Mon Nov 10 11:53:49 2008 Subject: [Haskell-cafe] Re: FFI documentation? In-Reply-To: <895610.1902.qm@web57405.mail.re1.yahoo.com> References: <895610.1902.qm@web57405.mail.re1.yahoo.com> Message-ID: > Where do I find the documentation for the FFI for GHC? I've read the > FFI report, the GHC user guide and scoured haskell.org but they all > gloss over what commands you actually need to give GHC and how to give > them. "foreign import blah blah" just gives me undefined references. One well documented and compiler independent way to do that is to use Cabal packages: http://www.haskell.org/ghc/docs/latest/html/Cabal/authors.html as used on Hackage: http://hackage.haskell.org If you have never done that, you will take some time to understand the role of the setup file (which in your case will problably be something like: import Distribution.Simple; main=defaultMain) and the details of .cabal files. (The problem you are concerned with is detailed in 3.1.4: Build Information. You'll see you can also list C files to be compiled with your code, and if you are using some library that implements the pkg-config standard then everything is really, really easy. I advise you to also understand well how 'build-depends' works and how to list language features out of Haskell 98 ? in your situation, at least 'extensions: ForeignFunctionInterface'.) Best, Maur?cio From bertram.felgenhauer at googlemail.com Mon Nov 10 12:05:34 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Mon Nov 10 12:00:36 2008 Subject: [Haskell-cafe] Histogram creation In-Reply-To: <8425cc0e0811100502u54fad0b5y14380ce589c5fb1a@mail.gmail.com> References: <8425cc0e0811100502u54fad0b5y14380ce589c5fb1a@mail.gmail.com> Message-ID: <20081110170534.GA4206@zombie.inf.tu-dresden.de> Alexey Khudyakov wrote: > Hello! > > I'm tryig to write efficient code for creating histograms. I have following > requirements for it: > > 1. O(1) element insertion > 2. No reallocations. Thus in place updates are needed. > > accumArray won't go because I need to fill a lot of histograms (hundrends) > from vely long list of data (possibly millions of elements) and it will > traverse input data for each histogram. That's just not true, for GHC's implementation of accumArray at least, which goes via the ST monad. It creates a mutable array, fills it, traversing the input list exactly once, and finally freezes the array and returns it. This is just what you suggest below. If you still run into performance problems, try out unboxed arrays. If that isn't enough, unsafeAccumArray from Data.Base may help. I'd try both before using the ST monad directly. > It seems that I need to use mutable array and/or ST monad or something else. > Sadly both of them are tricky and difficult to understand. So good examples > or any other ideas greatly appreciated. http://www.haskell.org/haskellwiki/Shootout/Nsieve_Bits perhaps. There must be better examples out there. I can think of two common problems with mutable arrays and ST: 1) You need to specify a type signature for the array being created, because the compiler can't guess the MArray instance that you want. For example, from the shootout entry: arr <- newArray (0,m) False :: IO (IOUArray Int Bool) In ST, this is slightly trickier, because the phantom 's' type parameter has to be mirrord in the ST*Array type constructor. You can use scoped type variables, which allow you to write {-# LANGUAGE ScopedTypeVariables #-} import Control.Monad.ST import Data.Array.ST foo :: forall s . ST s () foo = do arr <- newArray (0,42) False :: ST s (STUArray s Int Bool) ... Alternatively you can define helper functions to specify just the part of the type signature that you care about. stuArray :: ST s (STUArray s i e) -> ST s (STUArray s i e) stuArray = id foo :: ST s () foo = do arr <- stuArray $ newArray (0,42 :: Int) False ... 2) runST $ foo bar doesn't work. You have to write runST (foo bar) But in the end it's just imperative array programming with a rather verbose syntax -- you can do only one array access per statement, and 'readArray' and 'writeArray' are rather long names. HTH, Bertram From ryani.spam at gmail.com Mon Nov 10 13:07:03 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Nov 10 13:01:37 2008 Subject: [Haskell-cafe] Histogram creation In-Reply-To: <20081110170534.GA4206@zombie.inf.tu-dresden.de> References: <8425cc0e0811100502u54fad0b5y14380ce589c5fb1a@mail.gmail.com> <20081110170534.GA4206@zombie.inf.tu-dresden.de> Message-ID: <2f9b2d30811101007x3e83ec0duf19e87e2bbbbfa35@mail.gmail.com> On Mon, Nov 10, 2008 at 9:05 AM, Bertram Felgenhauer wrote: > 2) runST $ foo bar doesn't work. You have to write runST (foo bar) Isn't that fixed in GHC6.10? That was the impression I got from the FPH talk at ICFP. -- ryan From andrewcoppin at btinternet.com Mon Nov 10 13:19:39 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon Nov 10 13:14:10 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <1226333082.17214.36.camel@localhost> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> <4917379D.2020000@btinternet.com> <1226333082.17214.36.camel@localhost> Message-ID: <49187B3B.5050606@btinternet.com> Duncan Coutts wrote: > On Sun, 2008-11-09 at 19:18 +0000, Andrew Coppin wrote: > >> >> Generalised? Heck, I don't use list comprehension at all! :-P >> > > Perhaps you should! :-) > > When I first started with Haskell I kind of had the idea that list > comprehensions were just for beginners and that 'real' hackers used just > concatMaps and filters. > > A couple years later I 'rediscovered' list comprehensions and I now use > them frequently. There are many cases in real programs where simple and > not-so-simple list comprehensions are the clearest way of expressing the > solution. In particular the easy support for refutable pattern matching > in the generators allows some succinct and clear code. > I don't actually use *lists* all that much - or at least not list transformations. And if I'm going to do something complicated, I'll usually write it as a do-expression rather than a comprehension. > Just a random example out of Cabal: > > warn verbosity $ > "This package indirectly depends on multiple versions of the same " > ++ "package. This is highly likely to cause a compile failure.\n" > ++ unlines [ "package " ++ display pkg ++ " requires " > ++ display (PackageIdentifier name ver) > | (name, uses) <- inconsistencies > , (pkg, ver) <- uses ] > > Pretty concise and clear I think. > Erm... yeah, it's not too bad once I change all the formatting to make it clear what's what. Wouldn't it be a lot easier as a do-block though? From waldmann at imn.htwk-leipzig.de Mon Nov 10 13:20:09 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Nov 10 13:14:48 2008 Subject: [Haskell-cafe] download haskell? Message-ID: <49187B59.3060306@imn.htwk-leipzig.de> This is nit-picking, but ... when I go to haskell.org, there is a link (top in the left menu) "Download Haskell". Is this for readers who don't know the meaning of the word "implementation" (a few lines below)? Ah, it must be modelled after the perl.org start page... - J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081110/038a2fb7/signature.bin From andrewcoppin at btinternet.com Mon Nov 10 13:20:23 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon Nov 10 13:14:59 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> <4917379D.2020000@btinternet.com> <1226333082.17214.36.camel@localhost> Message-ID: <49187B67.7070702@btinternet.com> Mitchell, Neil wrote: > In general: > > if boolean then [value] else [] > > Can be written as: > > [value | boolean] > Is there any specific reason why this is valid? From andrewcoppin at btinternet.com Mon Nov 10 13:27:09 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon Nov 10 13:21:43 2008 Subject: [Haskell-cafe] Announce: FieldTrip library (functional 3D) and mailing list In-Reply-To: References: Message-ID: <49187CFD.7010401@btinternet.com> Conal Elliott wrote: > FieldTrip [1] is a library for functional 3D graphics. It is intended > for building static, animated, and interactive 3D geometry, efficient > enough for real-time synthesis and display. Since FieldTrip is > functional, one describes what models are, not how to render them > (being rather than doing). > > Surfaces are described as functions from 2D space to 3D space. As > such, they are intrinsically curved rather than faceted. Surface > rendering tessellates adaptively, caching tessellations in an > efficient, infinite data structure (from the MemoTrie library) for > reuse. Surface normals are computed automatically and exactly, using > the derivative tools in the vector-space library. > > For animation or interaction, FieldTrip can be used with the Reactive > [2] library for functional reactive programming (and possibly other > animation frameworks). By design, FieldTrip is completely orthogonal > to any formulation or implementation of FRP. The reactive-fieldtrip > [3] library links Reactive and FieldTrip. > > FieldTrip now has a mailing list [4] and a feature/bug tracker [5]. Sounds very interesting, but... what, no pictures? From a library especially designed for generating pictures? :-) From lrpalmer at gmail.com Mon Nov 10 13:30:13 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Nov 10 13:24:48 2008 Subject: [Haskell-cafe] download haskell? In-Reply-To: <49187B59.3060306@imn.htwk-leipzig.de> References: <49187B59.3060306@imn.htwk-leipzig.de> Message-ID: <7ca3f0160811101030j289fe832o937d6916a55a10ee@mail.gmail.com> 2008/11/10 Johannes Waldmann : > This is nit-picking, but ... when I go to haskell.org, there is a link > (top in the left menu) "Download Haskell". I think it's missing the words "to your brain". And the link goes to the wrong place. Luke From lrpalmer at gmail.com Mon Nov 10 13:32:12 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Nov 10 13:26:47 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <49187B67.7070702@btinternet.com> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> <4917379D.2020000@btinternet.com> <1226333082.17214.36.camel@localhost> <49187B67.7070702@btinternet.com> Message-ID: <7ca3f0160811101032m3cf80781x8df1851bdaa30c13@mail.gmail.com> Because expressions are treated as guards in list comprehensions. I.e.: [ foo | x <- a, b, y <- c, d ] Is interpreted as: do x <- a guard b y <- c guard d return foo Luke From jonathanccast at fastmail.fm Mon Nov 10 13:32:37 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Nov 10 13:27:10 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <49187B67.7070702@btinternet.com> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> <4917379D.2020000@btinternet.com> <1226333082.17214.36.camel@localhost> <49187B67.7070702@btinternet.com> Message-ID: <1226341957.11020.9.camel@jcchost> On Mon, 2008-11-10 at 18:20 +0000, Andrew Coppin wrote: > Mitchell, Neil wrote: > > In general: > > > > if boolean then [value] else [] > > > > Can be written as: > > > > [value | boolean] > > > > Is there any specific reason why this is valid? Is there any specific reason to dis-allow it? The grammar here looks something like (NB: I didn't double-check the report): list_compr ::= [ value | generator* ] generator ::= boolean | pat <- list | let binds One particular special case is where there is exactly one generator, which has three further special cases: [ value | boolean ] [ value | pat <- expr ] [ value | let binds ] These are all valid because they are special cases of the general list comprehension syntax; the de-sugarings are all just special cases of the general list comprehension de-sugaring rules: [ value | ] = [ value ] [ value | boolean, generators ] = if boolean then [ value | generators ] else [] [ value | pat <- expr, generators ] = expr >>= \ x -> case x of pat -> [ value | generators ]; _ -> [] [ value | let binds, generators ] = let binds in [ value | generators ] So the special cases simplify to [ value | boolean ] = if boolean then [ value ] else [] [ value | pat <- expr ] = expr >>= \ x -> case x of pat -> [ value ]; _ -> [] [ value | let binds ] = let binds in [ value ] Why wouldn't this work? jcc From jonathanccast at fastmail.fm Mon Nov 10 13:35:16 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Nov 10 13:29:48 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <49187B3B.5050606@btinternet.com> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> <4917379D.2020000@btinternet.com> <1226333082.17214.36.camel@localhost> <49187B3B.5050606@btinternet.com> Message-ID: <1226342116.11020.13.camel@jcchost> On Mon, 2008-11-10 at 18:19 +0000, Andrew Coppin wrote: > Duncan Coutts wrote: > > On Sun, 2008-11-09 at 19:18 +0000, Andrew Coppin wrote: > > > >> > >> Generalised? Heck, I don't use list comprehension at all! :-P > >> > > > > Perhaps you should! :-) > > > > When I first started with Haskell I kind of had the idea that list > > comprehensions were just for beginners and that 'real' hackers used just > > concatMaps and filters. > > > > A couple years later I 'rediscovered' list comprehensions and I now use > > them frequently. There are many cases in real programs where simple and > > not-so-simple list comprehensions are the clearest way of expressing the > > solution. In particular the easy support for refutable pattern matching > > in the generators allows some succinct and clear code. > > > > I don't actually use *lists* all that much - or at least not list > transformations. And if I'm going to do something complicated, I'll > usually write it as a do-expression rather than a comprehension. > > > Just a random example out of Cabal: > > > > warn verbosity $ > > "This package indirectly depends on multiple versions of the same " > > ++ "package. This is highly likely to cause a compile failure.\n" > > ++ unlines [ "package " ++ display pkg ++ " requires " > > ++ display (PackageIdentifier name ver) > > | (name, uses) <- inconsistencies > > , (pkg, ver) <- uses ] > > > > Pretty concise and clear I think. > > > > Erm... yeah, it's not too bad once I change all the formatting to make > it clear what's what. > > Wouldn't it be a lot easier as a do-block though? This was my first thought, too: warn verbosity $ "This package indirectly depends on multiple versions of the same " ++ "package. This is highly likely to cause a compile failure.\n" ++ do (name, uses) <- inconsistencies (pkg, ver) <- uses "package " ++ display pkg ++ " requires " ++ display (PackageIdentifier name ver) ++ "\n" is equivalent; it's at least clearer in that the generators come before the value, rather than after. jcc From andrewcoppin at btinternet.com Mon Nov 10 13:48:44 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon Nov 10 13:43:15 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <1226341957.11020.9.camel@jcchost> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> <4917379D.2020000@btinternet.com> <1226333082.17214.36.camel@localhost> <49187B67.7070702@btinternet.com> <1226341957.11020.9.camel@jcchost> Message-ID: <4918820C.4030809@btinternet.com> Jonathan Cast wrote: > On Mon, 2008-11-10 at 18:20 +0000, Andrew Coppin wrote: > >> Mitchell, Neil wrote: >> >>> In general: >>> >>> if boolean then [value] else [] >>> >>> Can be written as: >>> >>> [value | boolean] >>> >>> >> Is there any specific reason why this is valid? >> > > Is there any specific reason to dis-allow it? The grammar here looks > something like (NB: I didn't double-check the report): > > list_compr ::= [ value | generator* ] > generator ::= boolean | pat <- list | let binds > Hmm, that's interesting. I didn't know that a Boolean was a valid generator. (Presumably this has the effect of filtering?) The only time I use list comprehensions is when I quickly want a Cartesian product. I wasn't really aware it could filter as well. From duncan.coutts at worc.ox.ac.uk Mon Nov 10 13:50:25 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Nov 10 13:45:02 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <49187B67.7070702@btinternet.com> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> <4917379D.2020000@btinternet.com> <1226333082.17214.36.camel@localhost> <49187B67.7070702@btinternet.com> Message-ID: <1226343025.17214.85.camel@localhost> On Mon, 2008-11-10 at 18:20 +0000, Andrew Coppin wrote: > Mitchell, Neil wrote: > > In general: > > > > if boolean then [value] else [] > > > > Can be written as: > > > > [value | boolean] > > > > Is there any specific reason why this is valid? It is due to the rules for the translation of list comprehensions: [ e | True ] = [ e ] [ e | q ] = [ e | q, True ] [ e | b, Q ] = if b then [ e | Q ] else [] [ e | p <- l, Q ] = let ok p = [ e | Q ] ok _ = [] in concatMap ok l [ e | let decls, Q ] = let decls in [ e | Q ] So [ value | boolean ] matches the second rule giving us [value | boolean, True] which matches the third rule if boolean then [value | True] else [] which can be simplified via the first rule to if boolean then [value] else [] These rules are slightly more complex than necessary because they avoid using a null base case. We could simplify the first two rules if we were to allow the degenerate list comprehension [ e | ] and let Q match nothing. Then we'd use the rule: [ e | ] = [ e ] and translate [ value | boolean ] via the original 3rd rule with Q as nothing: if boolean then [value | ] else [] and directly to: if boolean then [value ] else [] If you meant, why is it allowed rather than banned then I guess the answer is because it is orthogonal. The rules naturally handle that case and there was no particular reason to ban it, even if it is somewhat unusual. Duncan From duncan.coutts at worc.ox.ac.uk Mon Nov 10 13:51:34 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Nov 10 13:46:09 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <49187B3B.5050606@btinternet.com> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> <4917379D.2020000@btinternet.com> <1226333082.17214.36.camel@localhost> <49187B3B.5050606@btinternet.com> Message-ID: <1226343094.17214.87.camel@localhost> On Mon, 2008-11-10 at 18:19 +0000, Andrew Coppin wrote: > I don't actually use *lists* all that much - or at least not list > transformations. And if I'm going to do something complicated, I'll > usually write it as a do-expression rather than a comprehension. > > > Just a random example out of Cabal: > > > > warn verbosity $ > > "This package indirectly depends on multiple versions of the same " > > ++ "package. This is highly likely to cause a compile failure.\n" > > ++ unlines [ "package " ++ display pkg ++ " requires " > > ++ display (PackageIdentifier name ver) > > | (name, uses) <- inconsistencies > > , (pkg, ver) <- uses ] > > > > Pretty concise and clear I think. > > > > Erm... yeah, it's not too bad once I change all the formatting to make > it clear what's what. > > Wouldn't it be a lot easier as a do-block though? I don't think so: ++ unlines $ do (name, uses) <- inconsistencies (pkg, ver) <- uses return $ "package " ++ display pkg ++ " requires " ++ display (PackageIdentifier name ver) Of course reasonable people may disagree. It's mostly aesthetics. Duncan From jonathanccast at fastmail.fm Mon Nov 10 13:54:01 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Nov 10 13:48:34 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <4918820C.4030809@btinternet.com> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> <4917379D.2020000@btinternet.com> <1226333082.17214.36.camel@localhost> <49187B67.7070702@btinternet.com> <1226341957.11020.9.camel@jcchost> <4918820C.4030809@btinternet.com> Message-ID: <1226343241.11020.16.camel@jcchost> On Mon, 2008-11-10 at 18:48 +0000, Andrew Coppin wrote: > Jonathan Cast wrote: > > On Mon, 2008-11-10 at 18:20 +0000, Andrew Coppin wrote: > > > >> Mitchell, Neil wrote: > >> > >>> In general: > >>> > >>> if boolean then [value] else [] > >>> > >>> Can be written as: > >>> > >>> [value | boolean] > >>> > >>> > >> Is there any specific reason why this is valid? > >> > > > > Is there any specific reason to dis-allow it? The grammar here looks > > something like (NB: I didn't double-check the report): > > > > list_compr ::= [ value | generator* ] > > generator ::= boolean | pat <- list | let binds > > > > Hmm, that's interesting. I didn't know that a Boolean was a valid generator. > > (Presumably this has the effect of filtering?) > > The only time I use list comprehensions is when I quickly want a > Cartesian product. I wasn't really aware it could filter as well. Funny. About the only time I use list comprehensions is when I want a generalized filter. Serious computations get the do-notation, instead. (And sometimes I *have* to use do-notation for filtering, because I need an error monad (usually Maybe) for other reasons). jcc From duncan.coutts at worc.ox.ac.uk Mon Nov 10 14:00:15 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Nov 10 13:54:53 2008 Subject: [Haskell-cafe] Histogram creation In-Reply-To: <20081110170534.GA4206@zombie.inf.tu-dresden.de> References: <8425cc0e0811100502u54fad0b5y14380ce589c5fb1a@mail.gmail.com> <20081110170534.GA4206@zombie.inf.tu-dresden.de> Message-ID: <1226343615.17214.96.camel@localhost> On Mon, 2008-11-10 at 18:05 +0100, Bertram Felgenhauer wrote: > Alexey Khudyakov wrote: > > Hello! > > > > I'm tryig to write efficient code for creating histograms. I have following > > requirements for it: > > > > 1. O(1) element insertion > > 2. No reallocations. Thus in place updates are needed. > > > > accumArray won't go because I need to fill a lot of histograms (hundrends) > > from vely long list of data (possibly millions of elements) and it will > > traverse input data for each histogram. > > That's just not true, for GHC's implementation of accumArray at least, > which goes via the ST monad. Perhaps I misunderstood but I think Alexey means that he wants to accumulate several different histograms (ie different arrays) but to only make one pass over the input data. The form of accumArray does not make that possible (unless one managed to pack the different histograms into different parts of the same array). If a fold using a pure persistent map type really is too slow then it should still be possible to do an ST implementation in a reasonably elegant way using a foldr on the input list, accumulating an ST action. Duncan From dons at galois.com Mon Nov 10 14:01:32 2008 From: dons at galois.com (Don Stewart) Date: Mon Nov 10 13:56:09 2008 Subject: [Haskell-cafe] download haskell? In-Reply-To: <49187B59.3060306@imn.htwk-leipzig.de> References: <49187B59.3060306@imn.htwk-leipzig.de> Message-ID: <20081110190132.GA23949@scytale.galois.com> waldmann: > This is nit-picking, but ... when I go to haskell.org, there is a link > (top in the left menu) "Download Haskell". Is this for readers who don't > know the meaning of the word "implementation" (a few lines below)? > Ah, it must be modelled after the perl.org start page... - J.W. > Exactly. One less thing to learn. For a similar reason, we don't motivate the language in terms of "higher-order, purely functional with monadic effects", but instead "rapid development of robust, concise, correct software" Keep things simple. -- Don From conal at conal.net Mon Nov 10 14:14:41 2008 From: conal at conal.net (Conal Elliott) Date: Mon Nov 10 14:09:15 2008 Subject: [Haskell-cafe] Announce: FieldTrip library (functional 3D) and mailing list In-Reply-To: <49187CFD.7010401@btinternet.com> References: <49187CFD.7010401@btinternet.com> Message-ID: Thanks for the prod, Andrew. (And thanks to Don S for prodding yesterday.) Now there's a picture on the FieldTrip page [1]. The shading is done using normals generated via derivatives from the vector-space package [2]. [1] http://haskell.org/haskellwiki/FieldTrip [2] http://haskell.org/haskellwiki/vector-space - Conal On Mon, Nov 10, 2008 at 10:27 AM, Andrew Coppin wrote: > Conal Elliott wrote: > >> FieldTrip [1] is a library for functional 3D graphics. It is intended for >> building static, animated, and interactive 3D geometry, efficient enough for >> real-time synthesis and display. Since FieldTrip is functional, one >> describes what models are, not how to render them (being rather than doing). >> >> Surfaces are described as functions from 2D space to 3D space. As such, >> they are intrinsically curved rather than faceted. Surface rendering >> tessellates adaptively, caching tessellations in an efficient, infinite data >> structure (from the MemoTrie library) for reuse. Surface normals are >> computed automatically and exactly, using the derivative tools in the >> vector-space library. >> >> For animation or interaction, FieldTrip can be used with the Reactive [2] >> library for functional reactive programming (and possibly other animation >> frameworks). By design, FieldTrip is completely orthogonal to any >> formulation or implementation of FRP. The reactive-fieldtrip [3] library >> links Reactive and FieldTrip. >> >> FieldTrip now has a mailing list [4] and a feature/bug tracker [5]. >> > > Sounds very interesting, but... what, no pictures? From a library > especially designed for generating pictures? :-) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081110/2ea3434d/attachment-0001.htm From andrewcoppin at btinternet.com Mon Nov 10 14:32:00 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon Nov 10 14:26:27 2008 Subject: [Haskell-cafe] Announce: FieldTrip library (functional 3D) and mailing list In-Reply-To: References: <49187CFD.7010401@btinternet.com> Message-ID: <49188C30.8050603@btinternet.com> Conal Elliott wrote: > Thanks for the prod, Andrew. (And thanks to Don S for prodding > yesterday.) > > Now there's a picture on the FieldTrip page [1]. The shading is done > using normals generated via derivatives from the vector-space package [2]. Mmm, nice. :-) (Actually... I just like shiny things!) What is the rendering backend? OpenGL? Or something else? Do you have any simple example code around? From andrewcoppin at btinternet.com Mon Nov 10 14:44:50 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon Nov 10 14:39:17 2008 Subject: [Haskell-cafe] Haskell Weekly News: Issue 92 - November 8, 2008 In-Reply-To: <20081108195336.GA15863@seas.upenn.edu> References: <20081108195336.GA15863@seas.upenn.edu> Message-ID: <49188F32.6060804@btinternet.com> Brent Yorgey wrote: > --------------------------------------------------------------------------- > Haskell Weekly News > http://sequence.complete.org/hwn/20081108 > Issue 92 - November 08, 2008 > --------------------------------------------------------------------------- > > GHC version 6.10.1. Ian Lynagh [2]announced the release of [3]GHC > version 6.10.1! This new major release features a number of significant > changes, including wild-card patterns, punning, and field > disambiguation in record syntax; generalised quasi-quotes; generalised > SQL-like list comprehensions; view patterns; a complete > reimplementation of type families; parallel garbage collection; a new > extensible exception framework; a more user-friendly API; included Data > Parallel Haskell (DPH); and more! See [4]the full release notes for > more information. > Were it not for this message, I might never have noticed! :-} (Presumably the main "announcement" was on one of the other Haskell lists...) Anyway, I don't see it anywhere in the release notes, but I get the vibe that type families are supposed to be "fully working" now. Is that correct? If so, why no mention anywhere? Also, the release notes tantelisingly hint that the long-awaited parallel-array stuff is finally working in this release, but I can't find any actual description of how to use it. All the DPH stuff seems on the wiki was last updated many months ago. You would have thought that such a big deal would be well-documented. It must have taken enough effort to get it to work! You'd think somebody would want to shout about it... From conal at conal.net Mon Nov 10 15:23:37 2008 From: conal at conal.net (Conal Elliott) Date: Mon Nov 10 15:18:10 2008 Subject: [Haskell-cafe] Announce: FieldTrip library (functional 3D) and mailing list In-Reply-To: <49188C30.8050603@btinternet.com> References: <49187CFD.7010401@btinternet.com> <49188C30.8050603@btinternet.com> Message-ID: We're using OpenGL as a rendering back-end. I've now added some sample code to the wiki page (http://haskell.org/haskellwiki/FieldTrip). It's very fast on my two-year-old machine. More examples are in src/Test.hs in the reactive-fieldtrip package. - Conal On Mon, Nov 10, 2008 at 11:32 AM, Andrew Coppin wrote: > Conal Elliott wrote: > >> Thanks for the prod, Andrew. (And thanks to Don S for prodding >> yesterday.) >> >> Now there's a picture on the FieldTrip page [1]. The shading is done >> using normals generated via derivatives from the vector-space package [2]. >> > > Mmm, nice. :-) > > (Actually... I just like shiny things!) > > What is the rendering backend? OpenGL? Or something else? > > Do you have any simple example code around? > > > _______________________________________________ > 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/20081110/29639f6d/attachment.htm From bertram.felgenhauer at googlemail.com Mon Nov 10 15:25:07 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Mon Nov 10 15:19:48 2008 Subject: [Haskell-cafe] Histogram creation In-Reply-To: <8425cc0e0811100502u54fad0b5y14380ce589c5fb1a@mail.gmail.com> References: <8425cc0e0811100502u54fad0b5y14380ce589c5fb1a@mail.gmail.com> Message-ID: <20081110202507.GB4206@zombie.inf.tu-dresden.de> Alexey Khudyakov wrote: > Hello! > > I'm tryig to write efficient code for creating histograms. I have following > requirements for it: > > 1. O(1) element insertion > 2. No reallocations. Thus in place updates are needed. > > > accumArray won't go because I need to fill a lot of histograms (hundrends) from > vely long list of data (possibly millions of elements) and it will traverse > input data for each histogram. Sorry, Duncan is right. I misread here. My first idea would still be to use accumArray though, or rather, accum, processing the input data in chunks of an appropriate size (which depends on the histogram sizes.) But actually, the ST code isn't bad (I hope this isn't homework): ------------------------------------------------------------------------ import Control.Monad.ST import Control.Monad import Data.Array.ST import Data.Array.Unboxed stuArray :: ST s (STUArray s i e) -> ST s (STUArray s i e) stuArray = id -- Create histograms. -- -- Each histogram is described by a pair (f, (l, u)), where 'f' maps -- a data entry to an Int index, and l and u are lower and upper bounds -- of the indices, respectively. -- mkHistograms :: [(a -> Int, (Int, Int))] -> [a] -> [UArray Int Int] mkHistograms hs ds = runST collect where -- Why is the type signature on 'collect' required here? collect :: ST s [UArray Int Int] collect = do -- create histogram arrays of appropriate sizes histograms <- forM hs $ \(_, range) -> do stuArray $ newArray range 0 -- iterate through the data forM_ ds $ \d -> do -- iterate through the histograms forM_ (zip hs histograms) $ \((f, _), h) -> do -- update appropriate entry writeArray h (f d) . succ =<< readArray h (f d) -- finally, freeze the histograms and return them -- (using unsafeFreeze is ok because we're done modifying the -- arrays) mapM unsafeFreeze histograms test = mkHistograms [((`mod` 3), (0,2)), ((`mod` 5), (0,4))] [0..10] -- test returns -- [array (0,2) [(0,4),(1,4),(2,3)], -- array (0,4) [(0,3),(1,2),(2,2),(3,2),(4,2)]] ------------------------------------------------------------------------ Bertram P.S. Ryan is right, too - I'm not sure where I got confused there. runST $ foo didn't work in ghc 6.6; I knew that it works in ghc 6.8.3, but I thought this was changed again. From wqeqweuqy at hotmail.com Mon Nov 10 15:30:14 2008 From: wqeqweuqy at hotmail.com (Neal Alexander) Date: Mon Nov 10 15:25:13 2008 Subject: [Haskell-cafe] ANN (sorta): OpenGL with extra type safety Message-ID: I recently modified the hOpenGL (and GLFW) source tree to force extra type checking on its various IO actions using the -XGeneralizedNewtypeDeriving extension (see http://hackage.haskell.org/trac/ghc/ticket/736). The main motivation was for writing concurrent OpenGL applications. Here its important to know what functions contain OpenGL commands so they can be directed to the proper threads (ones with active rendering contexts). Plus it aids in partitioning work that can be offloaded or done asynchronously. The second motivation was to enforce static type checking on commands that can only be executed in certain OpenGL contexts (sending vertex data for example). As it is now, there are 3 new monads (their names will probably change): OpenGLM: the basic opengl command PrimitiveM: commands that can only be issued between begin/end() class MonadGL: commands that can be issued in any GL context Now for the big question: Does anyone care? If so, should i make it a new hackageDB package, or try to merge it into the official GL package. Ideally, it'd be nice to get some more input on the API changes, since they're more or less a rough draft as is. Also, the GLU modules were all placed in the OpenGLM monad, which is probably wrong, assuming some commands can be called between begin/end. I'll post the code later if anyone is interested. ---------------- class MonadIO m => MonadGL m instance MonadGL OpenGLM instance MonadGL PrimitiveM newtype OpenGLM a = OpenGLM (IO a) deriving (Functor, Monad, MonadIO) newtype PrimitiveM a = PrimitiveM (IO a) deriving (Functor, Monad, MonadIO) From dons at galois.com Mon Nov 10 15:56:15 2008 From: dons at galois.com (Don Stewart) Date: Mon Nov 10 15:50:50 2008 Subject: [Haskell-cafe] ANN (sorta): OpenGL with extra type safety In-Reply-To: References: Message-ID: <20081110205615.GN23949@scytale.galois.com> wqeqweuqy: > I recently modified the hOpenGL (and GLFW) source tree to force extra > type checking on its various IO actions using the > -XGeneralizedNewtypeDeriving extension (see > http://hackage.haskell.org/trac/ghc/ticket/736). > > The main motivation was for writing concurrent OpenGL applications. Here > its important to know what functions contain OpenGL commands so they can > be directed to the proper threads (ones with active rendering contexts). > Plus it aids in partitioning work that can be offloaded or done > asynchronously. > > The second motivation was to enforce static type checking on commands > that can only be executed in certain OpenGL contexts (sending vertex > data for example). > > > As it is now, there are 3 new monads (their names will probably change): > > OpenGLM: the basic opengl command > PrimitiveM: commands that can only be issued between begin/end() > class MonadGL: commands that can be issued in any GL context > > > Now for the big question: Does anyone care? If so, should i make it a > new hackageDB package, or try to merge it into the official GL package. Yes, make a new package. Put it on hackage. Don't waste work, when it can be archived at the very least. -- Don From dominic.steinitz at blueyonder.co.uk Mon Nov 10 14:56:37 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Mon Nov 10 15:51:03 2008 Subject: [Haskell-cafe] Exporting a Type Class for Type Signatures Message-ID: <491891F5.7070908@blueyonder.co.uk> In the crypto package, I have two functions > encrypt :: AESKey a => a -> Word128 -> Word128 > decrypt :: AESKey a => a -> Word128 -> Word128 which are exported. I also have > class (Bits a, Integral a) => AESKey a > > instance AESKey Word128 > instance AESKey Word192 > instance AESKey Word256 unexported which stops you using invalid keys. Someone has asked me to export AESKey as they want to write an explicit type signature for a function they are creating e.g. foo :: AESKey a => a -> Word128 -> Word128 foo x y = encrypt x y but this generates an error. Is there a way of allowing someone to use AESKey in a type signature but not allow them to declare new instances? Thanks, Dominic. From bulat.ziganshin at gmail.com Mon Nov 10 16:17:36 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Nov 10 16:12:24 2008 Subject: [Haskell-cafe] Exporting a Type Class for Type Signatures In-Reply-To: <491891F5.7070908@blueyonder.co.uk> References: <491891F5.7070908@blueyonder.co.uk> Message-ID: <14510668684.20081111001736@gmail.com> Hello Dominic, Monday, November 10, 2008, 10:56:37 PM, you wrote: > but this generates an error. Is there a way of allowing someone to use > AESKey in a type signature but not allow them to declare new instances? afaik module AES (class AESKey,...) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jason.dusek at gmail.com Mon Nov 10 16:29:36 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Mon Nov 10 16:24:09 2008 Subject: [Haskell-cafe] catting to cat gets stuck at > 135K Message-ID: <42784f260811101329o6fde82f5x1a9636e4cd8ba948@mail.gmail.com> I've put together a simple test case for a rather annoying problem. I've got a program that drives other programs. For example, it can drive `cat`: :; Simple cat a-file When the file is a little bit greater than 135060 bytes, this program fails to produce any output at all -- I need to use ^C to get my console back. I have a similar program that encounters the same issue a little after 139192 bytes. The inconsistency is one baffling feature of this bug. If I remove the `hClose`, the example program just hangs, no matter the size of the input. It is entirely possible that I have overlooked some subtle feature of pipe semantics -- indeed, I hope that is the case. -- _jsn import Data.ByteString.Lazy import System.Process import System.Environment import System.IO (hClose) import Prelude hiding (writeFile, readFile) main = do exe:file:_ <- getArgs bytes <- readFile file foo <- simple exe bytes [] writeFile (file ++ ".foo") foo -- Manufactures a simple stream handler from a command line utility. simple :: String -> ByteString -> [String] -> IO ByteString simple exe bytes args = do (i, o, e, p) <- runInteractiveProcess exe args Nothing Nothing hPut i bytes s <- hGetContents o hClose i return s From allbery at ece.cmu.edu Mon Nov 10 16:37:48 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Nov 10 16:32:26 2008 Subject: [Haskell-cafe] catting to cat gets stuck at > 135K In-Reply-To: <42784f260811101329o6fde82f5x1a9636e4cd8ba948@mail.gmail.com> References: <42784f260811101329o6fde82f5x1a9636e4cd8ba948@mail.gmail.com> Message-ID: <5558E5DB-A741-4FF9-8596-FC70BC9BF835@ece.cmu.edu> On 2008 Nov 10, at 16:29, Jason Dusek wrote: > I've put together a simple test case for a rather annoying > problem. I've got a program that drives other programs. For > example, it can drive `cat`: > > :; Simple cat a-file > > When the file is a little bit greater than 135060 bytes, this > program fails to produce any output at all -- I need to use ^C > to get my console back. If you are feeding it input and collecting output, you need to forkIO one or both. In particular, the sequence feed input read output waitForProcess will deadlock if at any point the input or output pipe fills: one side will be blocked on write() waiting for the other side to read() from the pipe, while the read() side is blocked waiting for write() on the other pipe, which won't be read() because that's the first side. (There are other variants of this, but that's the general form: processes blocked each waiting for the other side to do something.) > If I remove the `hClose`, the example program just hangs, no > matter the size of the input. That's another symptom of it, yes, made worse because the pipe close is now implicit and the other side won't stop read()ing until the pipe is close()d by the first side. > simple exe bytes args = do > (i, o, e, p) <- runInteractiveProcess exe args > Nothing Nothing > hPut i bytes > s <- hGetContents o > hClose i > return s Yep, that's your problem. forkIO the hPut. -- 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 waldmann at imn.htwk-leipzig.de Mon Nov 10 16:44:29 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Nov 10 16:39:08 2008 Subject: [Haskell-cafe] download haskell? In-Reply-To: <20081110190132.GA23949@scytale.galois.com> References: <49187B59.3060306@imn.htwk-leipzig.de> <20081110190132.GA23949@scytale.galois.com> Message-ID: <4918AB3D.8070604@imn.htwk-leipzig.de> > Keep things simple. well I get the drift but for me, "download haskell" is a type error. you cannot download a programming language (imagine "download C"). anyway, I actually "downloaded haskell" today and built the shiny new ghc-6.10.1. best regards - J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081110/60c4ccfc/signature.bin From pieter at laeremans.org Mon Nov 10 17:05:11 2008 From: pieter at laeremans.org (Pieter Laeremans) Date: Mon Nov 10 16:59:44 2008 Subject: [Haskell-cafe] GHC 6.10 / Mac OS X / Library problem Message-ID: Hello, I've got a problem when I want to install pcre-light on OS X, with the latest version of GHC (binary package from haskell.org). It is not clear to me which flags to pass to ghc, to tell it to look at /opt/local/include for the pcre-light.h header. Any suggestions ? thanks, Pieter :cabal-install-0.6.0 pieter$ sudo cabal install pcre-light Password: Resolving dependencies... 'pcre-light-0.3.1' is cached. Configuring pcre-light-0.3.1... Preprocessing library pcre-light-0.3.1... Base.hsc:103:18: error: pcre.h: No such file or directory Base.hsc: In function 'main': Base.hsc:401: error: 'PCRE_ANCHORED' undeclared (first use in this function) Base.hsc:401: error: (Each undeclared identifier is reported only once Base.hsc:401: error: for each function it appears in.) Base.hsc:404: error: 'PCRE_AUTO_CALLOUT' undeclared (first use in this function) Base.hsc:407: error: 'PCRE_CASELESS' undeclared (first use in this function) Base.hsc:410: error: 'PCRE_DOLLAR_ENDONLY' undeclared (first use in this function) Base.hsc:413: error: 'PCRE_DOTALL' undeclared (first use in this function) Base.hsc:416: error: 'PCRE_DUPNAMES' undeclared (first use in this function) Base.hsc:419: error: 'PCRE_EXTENDED' undeclared (first use in this function) Base.hsc:422: error: 'PCRE_EXTRA' undeclared (first use in this function) Base.hsc:425: error: 'PCRE_FIRSTLINE' undeclared (first use in this function) Base.hsc:428: error: 'PCRE_MULTILINE' undeclared (first use in this function) Base.hsc:431: error: 'PCRE_NEWLINE_CR' undeclared (first use in this function) Base.hsc:434: error: 'PCRE_NEWLINE_CRLF' undeclared (first use in this function) Base.hsc:437: error: 'PCRE_NEWLINE_LF' undeclared (first use in this function) Base.hsc:440: error: 'PCRE_NO_AUTO_CAPTURE' undeclared (first use in this function) Base.hsc:443: error: 'PCRE_UNGREEDY' undeclared (first use in this function) Base.hsc:446: error: 'PCRE_UTF8' undeclared (first use in this function) Base.hsc:449: error: 'PCRE_NO_UTF8_CHECK' undeclared (first use in this function) Base.hsc:621: error: 'PCRE_NOTBOL' undeclared (first use in this function) Base.hsc:624: error: 'PCRE_NOTEOL' undeclared (first use in this function) Base.hsc:627: error: 'PCRE_NOTEMPTY' undeclared (first use in this function) Base.hsc:633: error: 'PCRE_PARTIAL' undeclared (first use in this function) Base.hsc:631: error: 'PCRE_ERROR_NOMATCH' undeclared (first use in this function) Base.hsc:634: error: 'PCRE_ERROR_NULL' undeclared (first use in this function) Base.hsc:637: error: 'PCRE_ERROR_BADOPTION' undeclared (first use in this function) Base.hsc:640: error: 'PCRE_ERROR_BADMAGIC' undeclared (first use in this function) Base.hsc:643: error: 'PCRE_ERROR_UNKNOWN_NODE' undeclared (first use in this function) Base.hsc:646: error: 'PCRE_ERROR_NOMEMORY' undeclared (first use in this function) Base.hsc:649: error: 'PCRE_ERROR_NOSUBSTRING' undeclared (first use in this function) Base.hsc:652: error: 'PCRE_ERROR_MATCHLIMIT' undeclared (first use in this function) Base.hsc:655: error: 'PCRE_ERROR_CALLOUT' undeclared (first use in this function) Base.hsc:658: error: 'PCRE_ERROR_BADUTF8' undeclared (first use in this function) Base.hsc:661: error: 'PCRE_ERROR_BADUTF8_OFFSET' undeclared (first use in this function) Base.hsc:664: error: 'PCRE_ERROR_PARTIAL' undeclared (first use in this function) Base.hsc:667: error: 'PCRE_ERROR_BADPARTIAL' undeclared (first use in this function) Base.hsc:670: error: 'PCRE_ERROR_INTERNAL' undeclared (first use in this function) Base.hsc:673: error: 'PCRE_ERROR_BADCOUNT' undeclared (first use in this function) Base.hsc:676: error: 'PCRE_ERROR_DFA_UITEM' undeclared (first use in this function) Base.hsc:679: error: 'PCRE_ERROR_DFA_UCOND' undeclared (first use in this function) Base.hsc:682: error: 'PCRE_ERROR_DFA_UMLIMIT' undeclared (first use in this function) Base.hsc:685: error: 'PCRE_ERROR_DFA_WSSIZE' undeclared (first use in this function) Base.hsc:688: error: 'PCRE_ERROR_DFA_RECURSE' undeclared (first use in this function) Base.hsc:691: error: 'PCRE_ERROR_RECURSIONLIMIT' undeclared (first use in this function) Base.hsc:665: error: 'PCRE_INFO_OPTIONS' undeclared (first use in this function) Base.hsc:668: error: 'PCRE_INFO_SIZE' undeclared (first use in this function) Base.hsc:671: error: 'PCRE_INFO_CAPTURECOUNT' undeclared (first use in this function) Base.hsc:674: error: 'PCRE_INFO_BACKREFMAX' undeclared (first use in this function) Base.hsc:677: error: 'PCRE_INFO_FIRSTBYTE' undeclared (first use in this function) Base.hsc:680: error: 'PCRE_INFO_FIRSTCHAR' undeclared (first use in this function) Base.hsc:683: error: 'PCRE_INFO_FIRSTTABLE' undeclared (first use in this function) Base.hsc:686: error: 'PCRE_INFO_LASTLITERAL' undeclared (first use in this function) Base.hsc:689: error: 'PCRE_INFO_NAMEENTRYSIZE' undeclared (first use in this function) Base.hsc:692: error: 'PCRE_INFO_NAMECOUNT' undeclared (first use in this function) Base.hsc:695: error: 'PCRE_INFO_NAMETABLE' undeclared (first use in this function) Base.hsc:698: error: 'PCRE_INFO_STUDYSIZE' undeclared (first use in this function) Base.hsc:701: error: 'PCRE_INFO_DEFAULT_TABLES' undeclared (first use in this function) Base.hsc:690: error: 'PCRE_CONFIG_UTF8' undeclared (first use in this function) Base.hsc:693: error: 'PCRE_CONFIG_NEWLINE' undeclared (first use in this function) Base.hsc:696: error: 'PCRE_CONFIG_LINK_SIZE' undeclared (first use in this function) Base.hsc:699: error: 'PCRE_CONFIG_POSIX_MALLOC_THRESHOLD' undeclared (first use in this function) Base.hsc:702: error: 'PCRE_CONFIG_MATCH_LIMIT' undeclared (first use in this function) Base.hsc:705: error: 'PCRE_CONFIG_STACKRECURSE' undeclared (first use in this function) Base.hsc:708: error: 'PCRE_CONFIG_UNICODE_PROPERTIES' undeclared (first use in this function) Base.hsc:711: error: 'PCRE_CONFIG_MATCH_LIMIT_RECURSION' undeclared (first use in this function) Base.hsc:724: error: 'PCRE_EXTRA_STUDY_DATA' undeclared (first use in this function) Base.hsc:727: error: 'PCRE_EXTRA_MATCH_LIMIT' undeclared (first use in this function) Base.hsc:730: error: 'PCRE_EXTRA_CALLOUT_DATA' undeclared (first use in this function) Base.hsc:733: error: 'PCRE_EXTRA_TABLES' undeclared (first use in this function) Base.hsc:736: error: 'PCRE_EXTRA_MATCH_LIMIT_RECURSION' undeclared (first use in this function) compiling dist/build/Text/Regex/PCRE/Light/Base_hsc_make.c failed command was: /usr/bin/gcc -c -D__GLASGOW_HASKELL__=610 -I/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/bytestring-0.9.1.4/include -I/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/base-4.0.0.0/include -I/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/include -IPAPI_INCLUDE_DIR dist/build/Text/Regex/PCRE/Light/Base_hsc_make.c -o dist/build/Text/Regex/PCRE/Light/Base_hsc_make.o cabal: Error: some packages failed to install: pcre-light-0.3.1 failed during the building phase. The exception was: exit: ExitFailure 1 -- Pieter Laeremans "The future is here. It's just not evenly distributed yet." W. Gibson From schlepptop at henning-thielemann.de Mon Nov 10 17:09:46 2008 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon Nov 10 17:00:58 2008 Subject: [Haskell-cafe] Are arbitrary rank types and existentials equivalent? In-Reply-To: <2f9b2d30811091422r342c92f6iceb9996a6aedd4a@mail.gmail.com> References: <6f9f8f4a0811090446s40d16dg748a500f4ed91230@mail.gmail.com> <2f9b2d30811091422r342c92f6iceb9996a6aedd4a@mail.gmail.com> Message-ID: <4918B12A.5090701@henning-thielemann.de> Ryan Ingram schrieb: > There's a natural relation between higher rank types and existentials; > one way to think about it is this: if you have some existential type t > (subject to some constraints), you cannot operate on it except with > some function that accepts any type t subject to those constraints. > > There is a simple encoding of existential types using higher rank types: > > Given >> data E a1..an = forall e1...en. (constraints) => E t1..tn > where t1..tn are types in terms of a1..an, we replace with >> data E' a1..an = E' (forall b. (forall e1..en. t1 -> t2 -> ... -> tn -> b) -> b) Can you please put this on the Wiki? From derek.a.elkins at gmail.com Mon Nov 10 17:06:29 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Mon Nov 10 17:01:11 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <1226343025.17214.85.camel@localhost> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> <4917379D.2020000@btinternet.com> <1226333082.17214.36.camel@localhost> <49187B67.7070702@btinternet.com> <1226343025.17214.85.camel@localhost> Message-ID: <1226354789.7139.9.camel@derek-laptop> On Mon, 2008-11-10 at 18:50 +0000, Duncan Coutts wrote: [...] > If you meant, why is it allowed rather than banned then I guess the > answer is because it is orthogonal. The rules naturally handle that case > and there was no particular reason to ban it, even if it is somewhat > unusual. "Unusual?" This is the motivation of list comprehensions. In naive set theory, set comprehensions are one way of an equivalence between predicates and sets. It's the Cartesian product aspect that should be considered unusual if anything. The binding aspect of list generators corresponds to naming the parameters of the predicate and then the Cartesian product aspect is simply the fact that a binary predicate, say, is a unary predicate on a binary Cartesian product. From wren at freegeek.org Mon Nov 10 17:08:40 2008 From: wren at freegeek.org (wren ng thornton) Date: Mon Nov 10 17:03:13 2008 Subject: [Haskell-cafe] Exporting a Type Class for Type Signatures In-Reply-To: <14510668684.20081111001736@gmail.com> References: <491891F5.7070908@blueyonder.co.uk> <14510668684.20081111001736@gmail.com> Message-ID: <4918B0E8.6080708@freegeek.org> Bulat Ziganshin wrote: > Hello Dominic, > > Monday, November 10, 2008, 10:56:37 PM, you wrote: > >> but this generates an error. Is there a way of allowing someone to use >> AESKey in a type signature but not allow them to declare new instances? > > afaik > > module AES (class AESKey,...) This seems not to work on ghc6.8.2 at least. $ cat AClass.hs ; ghc AClass.hs module AClass (class A) where class A a where f :: a -> () instance A () where f = id AClass.hs:1:15: parse error on input `class' Alas I don't know of any way to export a class for type signatures without exporting it for instantiation (corrections welcome :) There is, however, a fairly canonical hack if you're only concerned with the correctness of the code in your own library. You create an extra (empty) public class which is only an indirection for the real private class; and make sure your library only uses the real class. This way, even though clients can make new instances on the public class, that won't affect your own code. If your goal is to try to ensure the correctness of client code (not just the correctness of the library code), this trick doesn't help though. -- Live well, ~wren From jonathanccast at fastmail.fm Mon Nov 10 17:10:17 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Nov 10 17:04:50 2008 Subject: [Haskell-cafe] generalized list comprehensions In-Reply-To: <1226354789.7139.9.camel@derek-laptop> References: <4916078E.7090004@imn.htwk-leipzig.de> <9d4d38820811081543l339a5d5epe8a169d7649634ce@mail.gmail.com> <49162DFC.2050106@imn.htwk-leipzig.de> <9d4d38820811090215n8230fb1ldcd432b7ad7feb59@mail.gmail.com> <1226256475.12919.1.camel@derek-laptop> <4917379D.2020000@btinternet.com> <1226333082.17214.36.camel@localhost> <49187B67.7070702@btinternet.com> <1226343025.17214.85.camel@localhost> <1226354789.7139.9.camel@derek-laptop> Message-ID: <1226355017.11020.26.camel@jcchost> On Mon, 2008-11-10 at 16:06 -0600, Derek Elkins wrote: > On Mon, 2008-11-10 at 18:50 +0000, Duncan Coutts wrote: > [...] > > If you meant, why is it allowed rather than banned then I guess the > > answer is because it is orthogonal. The rules naturally handle that case > > and there was no particular reason to ban it, even if it is somewhat > > unusual. > > "Unusual?" This is the motivation of list comprehensions. > > In naive set theory, set comprehensions are one way of an equivalence > between predicates and sets. It's the Cartesian product aspect that > should be considered unusual if anything. Well, the Cartesian product case is one way of an equivalence between relations and sets of pairs. So I don't think it [ (x, y) | x <- xn, y <- ys ] is any more unusual than [ x | x <- xn ] jcc From dons at galois.com Mon Nov 10 17:12:21 2008 From: dons at galois.com (Don Stewart) Date: Mon Nov 10 17:06:58 2008 Subject: [Haskell-cafe] GHC 6.10 / Mac OS X / Library problem In-Reply-To: References: Message-ID: <20081110221221.GR23949@scytale.galois.com> pieter: > Hello, > > I've got a problem when I want to install pcre-light on OS X, with the > latest version of GHC (binary package from haskell.org). > > It is not clear to me which flags to pass to ghc, to tell it to look > at /opt/local/include for the pcre-light.h header. > Looks like pcre.h (the libpcre C library ) isn't installed. From aslatter at gmail.com Mon Nov 10 17:24:05 2008 From: aslatter at gmail.com (Antoine Latter) Date: Mon Nov 10 17:18:38 2008 Subject: [Haskell-cafe] Exporting a Type Class for Type Signatures In-Reply-To: <491891F5.7070908@blueyonder.co.uk> References: <491891F5.7070908@blueyonder.co.uk> Message-ID: <694519c50811101424h8981a8eh8715881ac7ea6e5d@mail.gmail.com> On Mon, Nov 10, 2008 at 1:56 PM, Dominic Steinitz wrote: > In the crypto package, I have two functions > >> encrypt :: AESKey a => a -> Word128 -> Word128 >> decrypt :: AESKey a => a -> Word128 -> Word128 > > which are exported. > > I also have > >> class (Bits a, Integral a) => AESKey a >> >> instance AESKey Word128 >> instance AESKey Word192 >> instance AESKey Word256 > > unexported which stops you using invalid keys. > > Someone has asked me to export AESKey as they want to write an explicit > type signature for a function they are creating e.g. > > foo :: AESKey a => a -> Word128 -> Word128 > foo x y = encrypt x y > > but this generates an error. Is there a way of allowing someone to use > AESKey in a type signature but not allow them to declare new instances? > > Thanks, Dominic. > Is there anything wrong with: > encrypt :: AESKey -> Word128 -> Word128 > data AESKey = Key128 Word128 | Key192 Word192 | Key256 Word256 Aside from the obvious that it's a breaking interface change. -Antoine From hpacheco at gmail.com Mon Nov 10 17:46:22 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Mon Nov 10 17:40:56 2008 Subject: [Haskell-cafe] GHC 6.10 / Mac OS X / Library problem In-Reply-To: References: Message-ID: <7b92c2840811101446v7f1aad02yf3fa49360028e8a1@mail.gmail.com> it is however. the same happened to me.you just need to run cabal install pcre-light --extra-include-dirs=/opt/local/include --extra-lib-dirs=/opt/local/lib My location is /opt/local, since I installed pcre via macports sudo port install pcre Bue I think pcre is installed by default in /Developer/SDKs/MacOSX10.5.sdk/usr/ Just check it out and report back. Good luck, hugo On Mon, Nov 10, 2008 at 10:12 PM, Don Stewart wrote: > pieter: > > Hello, > > > > I've got a problem when I want to install pcre-light on OS X, with the > > latest version of GHC (binary package from haskell.org). > > > > It is not clear to me which flags to pass to ghc, to tell it to look > > at /opt/local/include for the pcre-light.h header. > > > > Looks like pcre.h (the libpcre C library ) isn't installed. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081110/fb2b8829/attachment.htm From hpacheco at gmail.com Mon Nov 10 17:48:11 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Mon Nov 10 17:42:45 2008 Subject: [Haskell-cafe] Haskell source packages in Hackage In-Reply-To: <7b92c2840811100908n77a45180hfba15aea71466cf3@mail.gmail.com> References: <7b92c2840811100908n77a45180hfba15aea71466cf3@mail.gmail.com> Message-ID: <7b92c2840811101448u6797ce9aia7492ce3d3174feb@mail.gmail.com> Hi guys, I am having an hard time installing the haskell-src and haskell-src-exts packages, since both seem to have problems with happy. I have installed happy 1.18.2 successfully, but it does not seem to be visible (although the happy executable is in my path). I get the errors: $ cabal install haskell-src Resolving dependencies... 'haskell-src-1.0.1.3' is cached. Configuring haskell-src-1.0.1.3... Preprocessing library haskell-src-1.0.1.3... cabal: The program happy is required but it could not be found cabal: Error: some packages failed to install: haskell-src-1.0.1.3 failed during the building phase. The exception was: exit: ExitFailure 1 $ cabal install haskell-src-exts Resolving dependencies... 'haskell-src-exts-0.3.9' is cached. Configuring haskell-src-exts-0.3.9... cabal: happy version >=1.17 is required but it could not be found. cabal: Error: some packages failed to install: haskell-src-exts-0.3.9 failed during the configure step. The exception was: exit: ExitFailure 1 Is this some kind of bug in cabal, or in the packages themselves? Thanks, hugo -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081110/9f198de1/attachment.htm From ales.bizjak0 at gmail.com Mon Nov 10 17:59:32 2008 From: ales.bizjak0 at gmail.com (=?utf-8?B?QWxlxaEgQml6amFr?=) Date: Mon Nov 10 17:54:09 2008 Subject: [Haskell-cafe] GHC 6.10, strange behaviour when profiling? Message-ID: Hello, I'm experiencing some strange behaviour with GHC 6.10 and would like an explanation why. Here's the problem. With GHC 6.8.[23] memory usage of a program was about 250mb (computing pi to 10^6 decimals). Now I tried recompiling and running with GHC 6.10 and I got more than 1.4gb before I killed it, so naturally I tried profiling but here's the strangeness. When I compile for profiling with -prof -auto-all and run with +RTS -p -RTS memory use is still about the same as before (> 1.4gb), but when I try running with +RTS -hc -RTS memory only reaches about 250mb. What is the explanation for this behaviour? I would send a program but it requires HERA, which is not on hackage ... Here is the output of -s ./Test 100000 +RTS -s 47,467,176 bytes allocated in the heap 18,046,776 bytes copied during GC 9,215,104 bytes maximum residency (6 sample(s)) 711,520 bytes maximum slop 80 MB total memory in use (11 MB lost due to fragmentation) Generation 0: 84 collections, 0 parallel, 0.01s, 0.01s elapsed Generation 1: 6 collections, 0 parallel, 0.01s, 0.01s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 3.66s ( 3.71s elapsed) GC time 0.02s ( 0.02s elapsed) RP time 0.00s ( 0.00s elapsed) PROF time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 3.68s ( 3.73s elapsed) %GC time 0.5% (0.6% elapsed) Alloc rate 12,982,553 bytes per MUT second Productivity 99.5% of total user, 97.9% of total elapsed ./Test 100000 +RTS -s -hc 47,471,160 bytes allocated in the heap 18,637,752 bytes copied during GC 13,580,144 bytes maximum residency (37 sample(s)) 810,712 bytes maximum slop 33 MB total memory in use (7 MB lost due to fragmentation) Generation 0: 85 collections, 0 parallel, 0.02s, 0.02s elapsed Generation 1: 37 collections, 0 parallel, 0.00s, 0.01s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 3.67s ( 3.73s elapsed) GC time 0.02s ( 0.03s elapsed) RP time 0.00s ( 0.00s elapsed) PROF time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 3.70s ( 3.77s elapsed) %GC time 0.6% (0.8% elapsed) Alloc rate 12,941,165 bytes per MUT second Productivity 99.2% of total user, 97.4% of total elapsed -- Best regards, Ale? From dons at galois.com Mon Nov 10 18:03:01 2008 From: dons at galois.com (Don Stewart) Date: Mon Nov 10 17:57:35 2008 Subject: [Haskell-cafe] GHC 6.10, strange behaviour when profiling? In-Reply-To: References: Message-ID: <20081110230301.GB24736@scytale.galois.com> Could you please file this as a bug at this address, http://hackage.haskell.org/trac/ghc/newticket?type=bug Cheers, Don ales.bizjak0: > Hello, > > I'm experiencing some strange behaviour with GHC 6.10 and would like an > explanation why. > > Here's the problem. With GHC 6.8.[23] memory usage of a program was about > 250mb (computing pi to 10^6 decimals). > Now I tried recompiling and running with GHC 6.10 and I got more than > 1.4gb before I killed it, so naturally I tried profiling but > here's the strangeness. When I compile for profiling with -prof -auto-all > and run with +RTS -p -RTS memory use is > still about the same as before (> 1.4gb), but when I try running with +RTS > -hc -RTS memory only reaches about 250mb. > > What is the explanation for this behaviour? > > I would send a program but it requires HERA, which is not on hackage ... > > Here is the output of -s > > ./Test 100000 +RTS -s > 47,467,176 bytes allocated in the heap > 18,046,776 bytes copied during GC > 9,215,104 bytes maximum residency (6 sample(s)) > 711,520 bytes maximum slop > 80 MB total memory in use (11 MB lost due to fragmentation) > > Generation 0: 84 collections, 0 parallel, 0.01s, 0.01s elapsed > Generation 1: 6 collections, 0 parallel, 0.01s, 0.01s elapsed > > INIT time 0.00s ( 0.00s elapsed) > MUT time 3.66s ( 3.71s elapsed) > GC time 0.02s ( 0.02s elapsed) > RP time 0.00s ( 0.00s elapsed) > PROF time 0.00s ( 0.00s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 3.68s ( 3.73s elapsed) > > %GC time 0.5% (0.6% elapsed) > > Alloc rate 12,982,553 bytes per MUT second > > Productivity 99.5% of total user, 97.9% of total elapsed > > > > > ./Test 100000 +RTS -s -hc > 47,471,160 bytes allocated in the heap > 18,637,752 bytes copied during GC > 13,580,144 bytes maximum residency (37 sample(s)) > 810,712 bytes maximum slop > 33 MB total memory in use (7 MB lost due to fragmentation) > > Generation 0: 85 collections, 0 parallel, 0.02s, 0.02s elapsed > Generation 1: 37 collections, 0 parallel, 0.00s, 0.01s elapsed > > INIT time 0.00s ( 0.00s elapsed) > MUT time 3.67s ( 3.73s elapsed) > GC time 0.02s ( 0.03s elapsed) > RP time 0.00s ( 0.00s elapsed) > PROF time 0.00s ( 0.00s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 3.70s ( 3.77s elapsed) > > %GC time 0.6% (0.8% elapsed) > > Alloc rate 12,941,165 bytes per MUT second > > Productivity 99.2% of total user, 97.4% of total elapsed > > > > > -- > Best regards, Ale? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From mad.one at gmail.com Mon Nov 10 18:38:26 2008 From: mad.one at gmail.com (Austin Seipp) Date: Mon Nov 10 18:33:01 2008 Subject: [Haskell-cafe] Haskell Weekly News: Issue 92 - November 8, 2008 In-Reply-To: <49188F32.6060804@btinternet.com> References: <20081108195336.GA15863@seas.upenn.edu> <49188F32.6060804@btinternet.com> Message-ID: <1226359827-sup-9565@existential.local> > Anyway, I don't see it anywhere in the release notes, but I get the vibe > that type families are supposed to be "fully working" now. Is that > correct? If so, why no mention anywhere? Type families have been completely reimplemented and should be stable now, but there are some bugs - notably equality constraints in superclasses are not supported in GHC 6.10.1, i.e. > class (F a ~ b) => C a b where > type F a As indicated by this bug report: http://hackage.haskell.org/trac/ghc/ticket/2715 And here: http://haskell.org/haskellwiki/GHC/Indexed_types#Equality_constraints > Also, the release notes tantelisingly hint that the long-awaited > parallel-array stuff is finally working in this release, but I can't > find any actual description of how to use it. All the DPH stuff seems on > the wiki was last updated many months ago. You would have thought that > such a big deal would be well-documented. It must have taken enough > effort to get it to work! You'd think somebody would want to shout about > it... I put up a DPH version of the binarytrees benchmark in the shootout: http://haskell.org/haskellwiki/Shootout/Parallel/BinaryTreesDPH There are some notes there; the only documentation I really used was the documentation built by the GHC build process on the 'dph-*' libraries (you can see them in 6.10 by just doing 'ghc-pkg list' and looking through it.) I was thinking of porting more of the parallel shootout entries to use DPH, but I'm busy right now - results could be interesting. Austin From gtener at gmail.com Mon Nov 10 18:46:34 2008 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Mon Nov 10 18:41:07 2008 Subject: [Haskell-cafe] catting to cat gets stuck at > 135K In-Reply-To: <5558E5DB-A741-4FF9-8596-FC70BC9BF835@ece.cmu.edu> References: <42784f260811101329o6fde82f5x1a9636e4cd8ba948@mail.gmail.com> <5558E5DB-A741-4FF9-8596-FC70BC9BF835@ece.cmu.edu> Message-ID: <220e47b40811101546x14d016cdmde2bc93a6e7cfefc@mail.gmail.com> > > Yep, that's your problem. forkIO the hPut. > I can see the that thing biting a lot of people. Maybe there should be a warning in docs that this particular combination: > feed input > read output > waitForProcess is just likely to produce deadlocks? All best Christopher Skrz?tnicki From jason.dusek at gmail.com Mon Nov 10 19:04:07 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Mon Nov 10 18:58:42 2008 Subject: [Haskell-cafe] catting to cat gets stuck at > 135K In-Reply-To: <5558E5DB-A741-4FF9-8596-FC70BC9BF835@ece.cmu.edu> References: <42784f260811101329o6fde82f5x1a9636e4cd8ba948@mail.gmail.com> <5558E5DB-A741-4FF9-8596-FC70BC9BF835@ece.cmu.edu> Message-ID: <42784f260811101604q595bfaeam1c07d1a918fca7cd@mail.gmail.com> > > simple exe bytes args = do > > (i, o, e, p) <- runInteractiveProcess exe args Nothing > > Nothing > > hPut i bytes > > s <- hGetContents o > > hClose i > > return s > > Yep, that's your problem. forkIO the hPut. Maybe I didn't do enough here -- just wrapping in `forkIO` does not seem to actually help. -- _jsn import Data.ByteString.Lazy import System.Process import System.Environment import System.IO (hClose) import Control.Concurrent import Prelude hiding (writeFile, readFile) main = do exe:file:_ <- getArgs bytes <- readFile file foo <- simple exe bytes [] writeFile (file ++ ".foo") foo -- Manufactures a simple stream handler from a command line utility. simple :: String -> ByteString -> [String] -> IO ByteString simple exe bytes args = do (i, o, e, p) <- runInteractiveProcess exe args Nothing Nothing forkIO $ hPut i bytes s <- hGetContents o return s From korcan_h at hotmail.com Mon Nov 10 20:47:17 2008 From: korcan_h at hotmail.com (Korcan Hussein) Date: Mon Nov 10 20:41:51 2008 Subject: [Haskell-cafe] A video of Frag In-Reply-To: <7F7CDDDB-EE95-4891-96A8-15DC8174194C@pikewerks.com> References: <7b92c2840811100115n4e53e7f3tcecaea2c5acc059a@mail.gmail.com> <7F7CDDDB-EE95-4891-96A8-15DC8174194C@pikewerks.com> Message-ID: Okay so i've written a blog on how to build and run frag on windows @ http://monadickid.blogspot.com/2008/11/haskell-eye-for-windows-guy.html > CC: korcan_h@hotmail.com; haskell-cafe@haskell.org > From: jake@pikewerks.com > To: hpacheco@gmail.com > Subject: Re: [Haskell-cafe] A video of Frag > Date: Mon, 10 Nov 2008 08:22:20 -0600 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Nov 10, 2008, at 3:15 AM, Hugo Pacheco wrote: > > > Perhaps this effort could be targeted at creating a cabal package in > > Hackage > > It's already there. :) > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/frag > > - - Jake > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > > iEYEARECAAYFAkkYQ5wACgkQye5hVyvIUKkZCACgwy3VdzBfVTf8aIKxk67PAzgt > yyEAnjrbiaZTBQFqfI3jUSEn96Iv16GP > =Jwyf > -----END PGP SIGNATURE----- _________________________________________________________________ See the most popular videos on the web http://clk.atdmt.com/GBL/go/115454061/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081111/f938c543/attachment.htm From jason.dusek at gmail.com Mon Nov 10 20:49:21 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Mon Nov 10 20:43:53 2008 Subject: [Haskell-cafe] catting to cat gets stuck at > 135K In-Reply-To: <42784f260811101604q595bfaeam1c07d1a918fca7cd@mail.gmail.com> References: <42784f260811101329o6fde82f5x1a9636e4cd8ba948@mail.gmail.com> <5558E5DB-A741-4FF9-8596-FC70BC9BF835@ece.cmu.edu> <42784f260811101604q595bfaeam1c07d1a918fca7cd@mail.gmail.com> Message-ID: <42784f260811101749g19618848k7c5f63b826f222e0@mail.gmail.com> This does not work either. It should cover all the bases, right? Fork off input, pull things from ouput as they are ready, stop when we reach end of file. If you remove the line `print partial`, the program loops forever; if you keep it, the program stops right there. -- _jsn import Data.ByteString.Lazy hiding (putStrLn) import System.Process import System.Environment import System.IO (putStrLn, hClose, hWaitForInput) import System.IO.Error import Control.Concurrent import Prelude hiding (writeFile, readFile) main = do exe:file:_ <- getArgs bytes <- readFile file foo <- simple exe bytes [] writeFile (file ++ ".foo") foo -- Manufactures a simple stream handler from a command line utility. simple :: String -> ByteString -> [String] -> IO ByteString simple exe bytes args = do (i, o, e, p) <- runInteractiveProcess exe args Nothing Nothing pushAndPull i o bytes pushAndPull i o bytes = do putStrLn "Working with:" print bytes forkIO $ hPut i bytes putStrLn "forked" readUntilDone empty where readUntilDone soFar = do (const $ return soFar) `hctac` do putStrLn "hctac" hWaitForInput o 0 -- Wait as long as it takes. putStrLn "waited" partial <- hGetContents o putStrLn "contents:" print partial readUntilDone $ append soFar partial where hctac = flip catch From allbery at ece.cmu.edu Mon Nov 10 20:58:43 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Nov 10 20:53:24 2008 Subject: [Haskell-cafe] catting to cat gets stuck at > 135K In-Reply-To: <42784f260811101604q595bfaeam1c07d1a918fca7cd@mail.gmail.com> References: <42784f260811101329o6fde82f5x1a9636e4cd8ba948@mail.gmail.com> <5558E5DB-A741-4FF9-8596-FC70BC9BF835@ece.cmu.edu> <42784f260811101604q595bfaeam1c07d1a918fca7cd@mail.gmail.com> Message-ID: On 2008 Nov 10, at 19:04, Jason Dusek wrote: >>> simple exe bytes args = do >>> (i, o, e, p) <- runInteractiveProcess exe args Nothing >>> Nothing >>> hPut i bytes >>> s <- hGetContents o >>> hClose i >>> return s >> >> Yep, that's your problem. forkIO the hPut. > > Maybe I didn't do enough here -- just wrapping in `forkIO` > does not seem to actually help. *sigh* I hate the ghc runtime... it works in ghci, or compiled with - threaded. Otherwise you still get the deadlock because it only switches threads under limited circumstances (garbage collections?) which isn't nearly often enough. -- 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 df at dfranke.us Mon Nov 10 21:50:19 2008 From: df at dfranke.us (Daniel Franke) Date: Mon Nov 10 21:44:57 2008 Subject: [Haskell-cafe] catting to cat gets stuck at > 135K In-Reply-To: <42784f260811101604q595bfaeam1c07d1a918fca7cd@mail.gmail.com> (sfid-20081110_160427_506531_68A28943) (Jason Dusek's message of "Mon\, 10 Nov 2008 16\:04\:07 -0800") References: <42784f260811101329o6fde82f5x1a9636e4cd8ba948@mail.gmail.com> <5558E5DB-A741-4FF9-8596-FC70BC9BF835@ece.cmu.edu> <42784f260811101604q595bfaeam1c07d1a918fca7cd@mail.gmail.com> Message-ID: <873ahzdlhw.fsf@feanor.dfranke.us> "Jason Dusek" writes: >> > simple exe bytes args = do >> > (i, o, e, p) <- runInteractiveProcess exe args Nothing >> > Nothing >> > hPut i bytes >> > s <- hGetContents o >> > hClose i >> > return s >> >> Yep, that's your problem. forkIO the hPut. > > Maybe I didn't do enough here -- just wrapping in `forkIO` > does not seem to actually help. What GHC version are you using? Bugs #1780, #1936, and #2155 might be relevant. -- Daniel Franke df@dfranke.us http://www.dfranke.us |----| =|\ \\\\ || * | -|-\--------- Man is free at the instant he wants to be. -----| =| \ /// --Voltaire From DekuDekuplex at Yahoo.com Mon Nov 10 22:21:11 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Mon Nov 10 22:15:50 2008 Subject: [Haskell-cafe] Re: download haskell? References: <49187B59.3060306@imn.htwk-leipzig.de> Message-ID: On Mon, 10 Nov 2008 19:20:09 +0100, Johannes Waldmann wrote: >This is nit-picking, but ... when I go to haskell.org, there is a link >(top in the left menu) "Download Haskell". Is this for readers who don't >know the meaning of the word "implementation" (a few lines below)? >Ah, it must be modelled after the perl.org start page... - J.W. Although in order truly to model the perl.org start page, in line with their following link: download@ % perl Haskell's corresponding link should probably be (somewhat facetiously): download :: Click -> HaskellCompiler download GHC -- Benjamin L. Russell From jason.dusek at gmail.com Mon Nov 10 22:26:55 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Mon Nov 10 22:21:29 2008 Subject: [Haskell-cafe] catting to cat gets stuck at > 135K In-Reply-To: References: <42784f260811101329o6fde82f5x1a9636e4cd8ba948@mail.gmail.com> <5558E5DB-A741-4FF9-8596-FC70BC9BF835@ece.cmu.edu> <42784f260811101604q595bfaeam1c07d1a918fca7cd@mail.gmail.com> Message-ID: <42784f260811101926h66366676u5777e15da6978414@mail.gmail.com> That was just me being absent-minded -- I have threaded in my Cabal file but was not using it on the command line for my little test script. Thank you for calling it to my attention. -- _jsn From jason.dusek at gmail.com Mon Nov 10 23:49:35 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Mon Nov 10 23:44:08 2008 Subject: [Haskell-cafe] catting to cat gets stuck at > 135K In-Reply-To: <873ahzdlhw.fsf@feanor.dfranke.us> References: <42784f260811101329o6fde82f5x1a9636e4cd8ba948@mail.gmail.com> <5558E5DB-A741-4FF9-8596-FC70BC9BF835@ece.cmu.edu> <42784f260811101604q595bfaeam1c07d1a918fca7cd@mail.gmail.com> <873ahzdlhw.fsf@feanor.dfranke.us> Message-ID: <42784f260811102049i46f06434s13a159dc0d313bec@mail.gmail.com> I am using 6.8.3 -- it is almost exciting to realize how close I came to 'impossible' instead of 'annoying'. Living on the edge with UNIX IO! -- _jsn From oleg at okmij.org Tue Nov 11 01:21:55 2008 From: oleg at okmij.org (oleg@okmij.org) Date: Tue Nov 11 01:16:49 2008 Subject: [Haskell-cafe] Closed type classes [was: Exporting a Type Class for Type Signatures] Message-ID: <20081111062155.4D9EEAE54@Adric.metnet.fnmoc.navy.mil> Dominic Steinitz wrote: > In the crypto package, I have two functions > > encrypt :: AESKey a => a -> Word128 -> Word128 > > decrypt :: AESKey a => a -> Word128 -> Word128 but the class AESKey is not exported, to prevent the user from adding more instances to it. Since AESKey is not exported, the users cannot write signatures that mention that class constraint. The question is, how to export a _closed_ class -- a class the user cannot extend. Chung-chieh Shan and I had a similar problem in our TFP2007 paper: the classes that implement type-level arithmetic must be closed, to prevent the user from declaring that 1+1=1. It seems the best method is to use class aliases: In the implementation of AES, introduce class AESKey a => AESKeyExport a instance AESKey a => AESKeyExport a -- the only instance and now export AESKeyExport (but leave AESKey hidden). If the user needs to write the signature for their function: foo :: AESKeyExport a => a -> Word128 -> Word128 foo x y = encrypt x y they should use the constraint AESKeyExport a. That constraint entails AESKey a, which they cannot mention. The users can try to extend the class ESKeyExport a, but that would do them no good: the library uses the instances of AESKey rather than AESKeyExport. The TFP2007 paper explains that in a bit more detail: http://okmij.org/ftp/Computation/resource-aware-prog/tfp.pdf (Section 2.1). It also mentions a different method, relying on partial type signatures. From oleg at okmij.org Tue Nov 11 02:04:38 2008 From: oleg at okmij.org (oleg@okmij.org) Date: Tue Nov 11 01:59:29 2008 Subject: [Haskell-cafe] reliable (bi)directional pipe to a process Message-ID: <20081111070438.13467AE53@Adric.metnet.fnmoc.navy.mil> I'd like to point out a reliable, proven and simple way of interacting with another process, via unidirectional or bidirectional pipes. The method supports Unix sockets, pipes, and TCP sockets. I too have noticed insidious bugs in GHC run-time when communicating with another process via a pipe. I tried to use runInteractiveProcess; it worked -- up to file sizes of about 300Kb. Then GHC run-time seems to `loses synchronization' -- and corrupts IO buffers, receiving stuff that cannot have been possibly sent. This is because handle operations are asynchronous and the GHC scheduler seems to have race conditions. That behavior was totally unacceptable. I was writing a production code, and can't afford such errors. Therefore, I wrote a simple foreign function interface to the code sys_open that I have been using for about fifteen years. This code does work, in production, for very large file sizes and long-running processes, on many Unix and Unix-like systems. I was told once about a Cygwin port. http://okmij.org/ftp/syscall-interpose.html#Application http://okmij.org/ftp/packages/sys_open.c http://okmij.org/ftp/Haskell/MySysOpen.hs Please see the test at the end of the file MySysOpen.hs. The test interacts with another process over a bi-directional pipe, repeatedly sending and receiving data. The amount of received data is large (about 510K). From dons at galois.com Tue Nov 11 02:07:32 2008 From: dons at galois.com (Don Stewart) Date: Tue Nov 11 02:02:05 2008 Subject: [Haskell-cafe] reliable (bi)directional pipe to a process In-Reply-To: <20081111070438.13467AE53@Adric.metnet.fnmoc.navy.mil> References: <20081111070438.13467AE53@Adric.metnet.fnmoc.navy.mil> Message-ID: <20081111070732.GG25591@scytale.galois.com> oleg: > > I'd like to point out a reliable, proven and simple way of interacting > with another process, via unidirectional or bidirectional pipes. The > method supports Unix sockets, pipes, and TCP sockets. > > I too have noticed insidious bugs in GHC run-time when communicating > with another process via a pipe. I tried to use runInteractiveProcess; > it worked -- up to file sizes of about 300Kb. Then GHC run-time seems > to `loses synchronization' -- and corrupts IO buffers, receiving stuff > that cannot have been possibly sent. This is because handle operations > are asynchronous and the GHC scheduler seems to have race conditions. > That behavior was totally unacceptable. I was writing a production > code, and can't afford such errors. Did you file a bug report!? Can you follow up with information we can use to chase this down. > Therefore, I wrote a simple foreign function interface to the code > sys_open that I have been using for about fifteen years. This code > does work, in production, for very large file sizes and long-running > processes, on many Unix and Unix-like systems. I was told once about a > Cygwin port. > > http://okmij.org/ftp/syscall-interpose.html#Application > http://okmij.org/ftp/packages/sys_open.c > http://okmij.org/ftp/Haskell/MySysOpen.hs > > Please see the test at the end of the file MySysOpen.hs. The test > interacts with another process over a bi-directional pipe, repeatedly > sending and receiving data. The amount of received data is large > (about 510K). To file a bug, go here, http://hackage.haskell.org/trac/ghc/newticket?type=bug -- Don From ketil at malde.org Tue Nov 11 03:30:17 2008 From: ketil at malde.org (Ketil Malde) Date: Tue Nov 11 03:24:44 2008 Subject: [Haskell-cafe] Histogram creation In-Reply-To: <1226343615.17214.96.camel@localhost> (Duncan Coutts's message of "Mon\, 10 Nov 2008 19\:00\:15 +0000") References: <8425cc0e0811100502u54fad0b5y14380ce589c5fb1a@mail.gmail.com> <20081110170534.GA4206@zombie.inf.tu-dresden.de> <1226343615.17214.96.camel@localhost> Message-ID: <873ahyoeau.fsf@malde.org> Duncan Coutts writes: > Perhaps I misunderstood but I think Alexey means that he wants to > accumulate several different histograms (ie different arrays) but to > only make one pass over the input data. This is precicely my problem, too. > The form of accumArray does not make that possible (unless one > managed to pack the different histograms into different parts of the > same array). This would have been a good match for my case. Of course, that is a bit of a hack, and it would be much nicer and safer to do an accumArray with tuple elements. But I need to use an UArray in order to avoid the array filling up with unevaluated thunks, and - correct me if I'm wrong - there's no way to do a 'seq' before accumArray's insertion for complex types. So the stack blows up. /me wishes for s/Data.Array.Unboxed/Data.Array.Strict/g and instances for arbitrary types. Anyway, I thought of using offsets in the same UArray too late, and chose to finish my ST-based implementation instead. > If a fold using a pure persistent map type really is too slow then it > should still be possible to do an ST implementation in a reasonably > elegant way using a foldr on the input list, accumulating an ST action. Or must mapM_ an insert operation (in ST) over the input data? -k -- If I haven't seen further, it is by standing in the footprints of giants From jason.dusek at gmail.com Tue Nov 11 04:23:48 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Tue Nov 11 04:18:19 2008 Subject: [Haskell-cafe] Re: reliable (bi)directional pipe to a process In-Reply-To: <20081111070438.13467AE53@Adric.metnet.fnmoc.navy.mil> References: <20081111070438.13467AE53@Adric.metnet.fnmoc.navy.mil> Message-ID: <42784f260811110123u3ee3e41cke1fbafdad3fec8d4@mail.gmail.com> There is actually a real wealth of material on generalizing I/O on your site -- it's definitely something I will be ever more interested in. Now that I think about it, I can remember a time where a program that did a lot of stuff with Amazon would mysteriously run out of file descriptors, and I just had to put some shell around it to kick it over and over again. -- _jsn From dukedave at gmail.com Tue Nov 11 05:38:22 2008 From: dukedave at gmail.com (Dave Tapley) Date: Tue Nov 11 05:32:56 2008 Subject: [Haskell-cafe] What *not* to use Haskell for Message-ID: <1226399902.6496.9.camel@rubix.office.last.fm> Hi everyone So I should clarify I'm not a troll and do "see the Haskell light". But one thing I can never answer when preaching to others is "what does Haskell not do well?" Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) Cheers, Dave From nominolo at googlemail.com Tue Nov 11 05:54:57 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Nov 11 05:49:28 2008 Subject: [Haskell-cafe] GHC 6.10, strange behaviour when profiling? In-Reply-To: References: Message-ID: <916b84820811110254q61b5211dl1d93fef26432c69a@mail.gmail.com> I think you hit bug http://hackage.haskell.org/trac/ghc/ticket/2747, which is an accounting bug in the garbage collector and goes away when you trigger more garbage collections (which -hc does, I think). Please file a bug report anyway, so we can verify that it is indeed not a new bug. (Since the profiler modifies the program it can turn on or off different optimisations, so it's quite possible that there are other reasons for this behaviour.) 2008/11/10 Ale? Bizjak : > Hello, > > I'm experiencing some strange behaviour with GHC 6.10 and would like an > explanation why. > > Here's the problem. With GHC 6.8.[23] memory usage of a program was about > 250mb (computing pi to 10^6 decimals). > Now I tried recompiling and running with GHC 6.10 and I got more than 1.4gb > before I killed it, so naturally I tried profiling but > here's the strangeness. When I compile for profiling with -prof -auto-all > and run with +RTS -p -RTS memory use is > still about the same as before (> 1.4gb), but when I try running with +RTS > -hc -RTS memory only reaches about 250mb. > > What is the explanation for this behaviour? > > I would send a program but it requires HERA, which is not on hackage ... > > Here is the output of -s > > ./Test 100000 +RTS -s > 47,467,176 bytes allocated in the heap > 18,046,776 bytes copied during GC > 9,215,104 bytes maximum residency (6 sample(s)) > 711,520 bytes maximum slop > 80 MB total memory in use (11 MB lost due to fragmentation) > > Generation 0: 84 collections, 0 parallel, 0.01s, 0.01s elapsed > Generation 1: 6 collections, 0 parallel, 0.01s, 0.01s elapsed > > INIT time 0.00s ( 0.00s elapsed) > MUT time 3.66s ( 3.71s elapsed) > GC time 0.02s ( 0.02s elapsed) > RP time 0.00s ( 0.00s elapsed) > PROF time 0.00s ( 0.00s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 3.68s ( 3.73s elapsed) > > %GC time 0.5% (0.6% elapsed) > > Alloc rate 12,982,553 bytes per MUT second > > Productivity 99.5% of total user, 97.9% of total elapsed > > > > > ./Test 100000 +RTS -s -hc > 47,471,160 bytes allocated in the heap > 18,637,752 bytes copied during GC > 13,580,144 bytes maximum residency (37 sample(s)) > 810,712 bytes maximum slop > 33 MB total memory in use (7 MB lost due to fragmentation) > > Generation 0: 85 collections, 0 parallel, 0.02s, 0.02s elapsed > Generation 1: 37 collections, 0 parallel, 0.00s, 0.01s elapsed > > INIT time 0.00s ( 0.00s elapsed) > MUT time 3.67s ( 3.73s elapsed) > GC time 0.02s ( 0.03s elapsed) > RP time 0.00s ( 0.00s elapsed) > PROF time 0.00s ( 0.00s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 3.70s ( 3.77s elapsed) > > %GC time 0.6% (0.8% elapsed) > > Alloc rate 12,941,165 bytes per MUT second > > Productivity 99.2% of total user, 97.4% of total elapsed > > > > > -- > Best regards, Ale? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From waldmann at imn.htwk-leipzig.de Tue Nov 11 05:55:55 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue Nov 11 05:50:35 2008 Subject: [Haskell-cafe] Re: reliable (bi)directional pipe to a process References: <20081111070438.13467AE53@Adric.metnet.fnmoc.navy.mil> Message-ID: > I too have noticed insidious bugs in GHC run-time when communicating > with another process via a pipe. I tried to use runInteractiveProcess; > it worked -- up to file sizes of about 300Kb. Yeah, I seem to be running into similar strange problems, so I'll be definitely checking out your code. (Why didn't I file bug reports? Because I couldn't isolate the problem well, so my whole setup including external programs would have to be duplicated, and I don't expect GHC headquarters to be willing to do this. No complaints.) J.W. From nominolo at googlemail.com Tue Nov 11 05:58:03 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Nov 11 05:52:35 2008 Subject: [Haskell-cafe] Re: download haskell? In-Reply-To: References: <49187B59.3060306@imn.htwk-leipzig.de> Message-ID: <916b84820811110258v6ccd59c8le1807fd2847ab4ab@mail.gmail.com> 2008/11/11 Benjamin L. Russell : > Haskell's corresponding link should probably be (somewhat > facetiously): > > download :: Click -> HaskellCompiler > download GHC parse error (possibly incorrect indentation) From jpm at cs.uu.nl Tue Nov 11 06:11:03 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Tue Nov 11 06:05:35 2008 Subject: [Haskell-cafe] Proposal for associated type synonyms in Template Haskell In-Reply-To: <4911B442.7080104@cs.ru.nl> References: <49104B62.5010308@cs.ru.nl> <491052AB.2010302@cs.ru.nl> <4b39c80a0811040600y16257eafh5037a851284af10e@mail.gmail.com> <4911B442.7080104@cs.ru.nl> Message-ID: <52f14b210811110311v8ab419au5f33b08b9681f84d@mail.gmail.com> Hello Thomas, I see this is a proposal for a partial implementation of #1673 ( http://hackage.haskell.org/trac/ghc/ticket/1673). Maybe it would be good if the remaining syntax (associated datatypes and type families) would also be defined and implemented in TH. Or maybe there isn't much demand for this?... Cheers, Pedro On Wed, Nov 5, 2008 at 15:57, Thomas van Noort wrote: > Hello, > > Recently, we released a library on Hackage for generic rewriting (package > "rewriting" if you are curious). The user of the library is expected to > define type class instances to enable rewriting on his or her own datatypes. > As these instances follow the datatype declarations closely, we tried to > generate the instances using Template Haskell. Unfortunately, associated > type synonyms are not yet supported by TH. > > After a presentation at the WGP'08, Simon encouraged us to write a proposal > about adding associated type synonyms to TH, so that it can be added to GHC. > So, here is our proposal. > > The TH AST must allow 1) kind declarations of associated type synonyms > in class declarations and 2) their definitions in instance declarations. > For example, > > class Foo a where > type Bar a :: * > > instance Foo Int where > type Bar Int = String > > The TH library defines a datatype Dec which contains a constructor for > class declarations and instance declarations: > > data Dec > = ... > | ClassD Cxt Name [Name] [FunDep] [Dec] > | InstanceD Cxt Type [Dec] > ... > > 1) Associated type synonym kind declarations > > We suggest to add a constructor to the Dec type: > > ... > | AssocTySynKindD Name [Name] (Maybe Kind) > ... > > assocTySynKindD :: Name -> [Name] -> Maybe KindQ -> DecQ > > The first field is the name of the associated type synonym, the second > field is a list of type variables, and the third field is an optional kind. > Since kinds are not yet defined in TH, we have to add some kind of kind > definition (pun intended): > > data Kind > = StarK > | ArrowK Kind Kind > > type KindQ = Q Kind > starK :: KindQ > arrowK :: KindQ -> KindQ -> KindQ > > We explicitly choose not to reuse the Type type to define kinds (i.e., type > Kind = Type as in GHC) since we think a separation between the two worlds is > much clearer to the users of TH. > > 2) Associated type synonym definitions > > We suggest to add another constructor to the Dec type: > > ... > | AssocTySynD Name [Type] Type > ... > > assocTySynD :: Name -> [TypeQ] -> TypeQ -> DecQ > > The first field is the name of the type synonym, the second field is a list > of type arguments, and the third field is the body of the type synonym. > > We would like to hear your comments to this proposal. > > Regards, > Thomas > _______________________________________________ > 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/20081111/262ce609/attachment.htm From jules at jellybean.co.uk Tue Nov 11 06:18:12 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Tue Nov 11 06:12:45 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <1226399902.6496.9.camel@rubix.office.last.fm> References: <1226399902.6496.9.camel@rubix.office.last.fm> Message-ID: <491969F4.6000300@jellybean.co.uk> Dave Tapley wrote: > Hi everyone > > So I should clarify I'm not a troll and do "see the Haskell light". But > one thing I can never answer when preaching to others is "what does > Haskell not do well?" > > Usually I'll avoid then question and explain that it is a 'complete' > language and we do have more than enough libraries to make it useful and > productive. But I'd be keen to know if people have any anecdotes, > ideally ones which can subsequently be twisted into an argument for > Haskell ;) GHC's scheduler lacks any hard timeliness guarantees. Thus it's quite hard to use haskell in realtime or even soft-realtime environments. This is probably not a fundamental problem with haskell. It's a problem with the compiler/RTS which we happen to be using. It may be true that it's harder to write an RTS with realtime guarantees but I doubt it's impossible. Jules From Malcolm.Wallace at cs.york.ac.uk Tue Nov 11 06:23:01 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Nov 11 06:18:57 2008 Subject: [Haskell-cafe] Exporting a Type Class for Type Signatures In-Reply-To: <491891F5.7070908@blueyonder.co.uk> References: <491891F5.7070908@blueyonder.co.uk> Message-ID: <20081111112301.56b7ed0b.Malcolm.Wallace@cs.york.ac.uk> Dominic Steinitz wrote: > Is there a way of allowing someone to use > AESKey in a type signature but not allow them to declare new > instances? I was going to suggest you export the class abstractly, that is, without its methods, so no-one could externally create an instance. But then I noticed that AESKey has no methods - it is just an alias for a combination of other classes - so that trick is insufficient. So, the other thing you could do is to introduce an indirection. module This (AESKey) where class (Bits a, Integral a) => AESKeyIndirection a -- un-exported class (AESKeyIndirection a) => AESKey a -- exported instance AESKeyIndirection Word128 instance AESKeyIndirection Word192 instance AESKeyIndirection Word256 instance AESKey Word128 instance AESKey Word192 instance AESKey Word256 Creating an instance of AESKey requires that you also create an instance of AESKeyIndirection. If only one of the names is available externally (exported), then instances can only be created internal to the module. Regards, Malcolm From briqueabraque at yahoo.com Tue Nov 11 06:26:21 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Tue Nov 11 06:21:01 2008 Subject: [Haskell-cafe] Re: What *not* to use Haskell for In-Reply-To: <1226399902.6496.9.camel@rubix.office.last.fm> References: <1226399902.6496.9.camel@rubix.office.last.fm> Message-ID: I think Haskell is not nice to write general purpouse libraries that could be easily and completly wrapped by other languages. You can wrap gtk, sqlite3, gsl, opengl etc., but you can't write python bindings for Data.Graph. But, then, if you claim there's nothing else Haskell can't do, what do you need those bindings for ? :) Best, Maur?cio > Hi everyone > > So I should clarify I'm not a troll and do "see the Haskell light". But > one thing I can never answer when preaching to others is "what does > Haskell not do well?" > > Usually I'll avoid then question and explain that it is a 'complete' > language and we do have more than enough libraries to make it useful and > productive. But I'd be keen to know if people have any anecdotes, > ideally ones which can subsequently be twisted into an argument for > Haskell ;) > > Cheers, > > Dave From arnarbi at gmail.com Tue Nov 11 06:32:11 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Tue Nov 11 06:26:41 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <1226399902.6496.9.camel@rubix.office.last.fm> References: <1226399902.6496.9.camel@rubix.office.last.fm> Message-ID: <28012bc60811110332q7e369abcq36632b3788061ca8@mail.gmail.com> Hi all, On Tue, Nov 11, 2008 at 11:38, Dave Tapley wrote: > Usually I'll avoid then question and explain that it is a 'complete' > language and we do have more than enough libraries to make it useful and > productive. But I'd be keen to know if people have any anecdotes, > ideally ones which can subsequently be twisted into an argument for > Haskell ;) I would not use Haskell if I were faced with the prospect of producing a huge system in short time (i.e. meaning I couldn't do it by myself) and all I had was a pool of "regular" programmers that have been trained in .NET, Java, C++, Python, . Yes, sad - but true. I'd very much like to see this twisted to an argument for Haskell :) cheers, Arnar From bulat.ziganshin at gmail.com Tue Nov 11 06:35:19 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 11 06:30:11 2008 Subject: [Haskell-cafe] Re: What *not* to use Haskell for In-Reply-To: References: <1226399902.6496.9.camel@rubix.office.last.fm> Message-ID: <1254110628.20081111143519@gmail.com> Hello Mauricio, Tuesday, November 11, 2008, 2:26:21 PM, you wrote: imho, Haskell isn't worse here than any other compiled language - C++, ML, Eiffel and beter tnan Java or C#.every language has its own object model and GC. the only ay is to provide C-typed interfaces between languages (or use COM, IDL and other API-describing languages) > I think Haskell is not nice to write general purpouse libraries > that could be easily and completly wrapped by other languages. > You can wrap gtk, sqlite3, gsl, opengl etc., but you can't write > python bindings for Data.Graph. > But, then, if you claim there's nothing else Haskell can't do, > what do you need those bindings for ? :) > Best, > Mauricio >> Hi everyone >> >> So I should clarify I'm not a troll and do "see the Haskell light". But >> one thing I can never answer when preaching to others is "what does >> Haskell not do well?" >> >> Usually I'll avoid then question and explain that it is a 'complete' >> language and we do have more than enough libraries to make it useful and >> productive. But I'd be keen to know if people have any anecdotes, >> ideally ones which can subsequently be twisted into an argument for >> Haskell ;) >> >> Cheers, >> >> Dave > _______________________________________________ > 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 hpacheco at gmail.com Tue Nov 11 07:20:28 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Tue Nov 11 07:31:26 2008 Subject: [Haskell-cafe] compiling haskell-src-exts in 6.10 Message-ID: <7b92c2840811110420i370e124dl616373df08373d7e@mail.gmail.com> When installing package haskell-src-exts via cabal install, I get the error Language/Haskell/Exts/Syntax.hs:102:7: Could not find module `Data.Data': it is a member of package base, which is hidden However, when manually installing runhaskell Setup.hs configure/build/install It works fine Somehow package base is not available in cabal.. don't know why. hugo -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081111/4cfaba3b/attachment.htm From Christian.Maeder at dfki.de Tue Nov 11 07:51:03 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Nov 11 07:45:32 2008 Subject: [Haskell-cafe] Re: GHC 6.10 / Mac OS X / Library problem In-Reply-To: <7b92c2840811101446v7f1aad02yf3fa49360028e8a1@mail.gmail.com> References: <7b92c2840811101446v7f1aad02yf3fa49360028e8a1@mail.gmail.com> Message-ID: <49197FB7.8000209@dfki.de> Hugo Pacheco wrote: > it is however. the same happened to me. > you just need to run > > cabal install pcre-light --extra-include-dirs=/opt/local/include > --extra-lib-dirs=/opt/local/lib > > My location is /opt/local, since I installed pcre via macports > > sudo port install pcre Alternatively: export CPATH=/opt/local/include export LIBRARY_PATH=/opt/local/lib export LD_LIBRARY_PATH=/opt/local/lib export DYLD_LIBRARY_PATH=/opt/local/lib should work, too C. From jefferson.r.heard at gmail.com Tue Nov 11 08:12:40 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Tue Nov 11 08:07:13 2008 Subject: [Haskell-cafe] Re: What *not* to use Haskell for In-Reply-To: <1254110628.20081111143519@gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <1254110628.20081111143519@gmail.com> Message-ID: <4165d3a70811110512n5e485595of1851a1647ffea96@mail.gmail.com> Actually, one language you mention there *is* worse than the others for writing wrappable library code: C++. Admittedly, they've got a Python interface now via boost, but the main problem with writing wrappable C++ code is the template system and the inheritence systems getting in the way. Symbol names aren't predictable and not standardized, so it becomes impossible to write a portable system for finding and binding to functions in a library. I've not yet found a good way to do it in FFI code, and I would love to, as one library in particular I hold near and dear -- OpenSceneGraph -- is entirely written in C++. -- Jeff On Tue, Nov 11, 2008 at 6:35 AM, Bulat Ziganshin wrote: > Hello Mauricio, > > Tuesday, November 11, 2008, 2:26:21 PM, you wrote: > > imho, Haskell isn't worse here than any other compiled language - C++, > ML, Eiffel and beter tnan Java or C#.every language has its own object > model and GC. the only ay is to provide C-typed interfaces between > languages (or use COM, IDL and other API-describing languages) > >> I think Haskell is not nice to write general purpouse libraries >> that could be easily and completly wrapped by other languages. >> You can wrap gtk, sqlite3, gsl, opengl etc., but you can't write >> python bindings for Data.Graph. > >> But, then, if you claim there's nothing else Haskell can't do, >> what do you need those bindings for ? :) > >> Best, >> Mauricio > >>> Hi everyone >>> >>> So I should clarify I'm not a troll and do "see the Haskell light". But >>> one thing I can never answer when preaching to others is "what does >>> Haskell not do well?" >>> >>> Usually I'll avoid then question and explain that it is a 'complete' >>> language and we do have more than enough libraries to make it useful and >>> productive. But I'd be keen to know if people have any anecdotes, >>> ideally ones which can subsequently be twisted into an argument for >>> Haskell ;) >>> >>> Cheers, >>> >>> Dave > >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From kr.angelov at gmail.com Tue Nov 11 08:37:37 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Tue Nov 11 08:32:11 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <28012bc60811110332q7e369abcq36632b3788061ca8@mail.gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <28012bc60811110332q7e369abcq36632b3788061ca8@mail.gmail.com> Message-ID: You can hire one Haskell programmer instead of 1,2,3... programmers in your favorite imperative language. On Tue, Nov 11, 2008 at 12:32 PM, Arnar Birgisson wrote: > Hi all, > > On Tue, Nov 11, 2008 at 11:38, Dave Tapley wrote: >> Usually I'll avoid then question and explain that it is a 'complete' >> language and we do have more than enough libraries to make it useful and >> productive. But I'd be keen to know if people have any anecdotes, >> ideally ones which can subsequently be twisted into an argument for >> Haskell ;) > > I would not use Haskell if I were faced with the prospect of producing > a huge system in short time (i.e. meaning I couldn't do it by myself) > and all I had was a pool of "regular" programmers that have been > trained in .NET, Java, C++, Python, language>. > > Yes, sad - but true. I'd very much like to see this twisted to an > argument for Haskell :) > > cheers, > Arnar > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From arnarbi at gmail.com Tue Nov 11 08:43:13 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Tue Nov 11 08:37:44 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: References: <1226399902.6496.9.camel@rubix.office.last.fm> <28012bc60811110332q7e369abcq36632b3788061ca8@mail.gmail.com> Message-ID: <28012bc60811110543rcf749e5v4a37cd2beeba1adf@mail.gmail.com> On Tue, Nov 11, 2008 at 14:37, Krasimir Angelov wrote: > You can hire one Haskell programmer instead of 1,2,3... programmers in > your favorite imperative language. That's assuming I can find a Haskell programmer in the first place. Also, he/she has to be good to replace 10 other programmers. cheers, Arnar From lemming at henning-thielemann.de Tue Nov 11 08:46:52 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Nov 11 08:41:43 2008 Subject: [Haskell-cafe] Re: What *not* to use Haskell for In-Reply-To: <4165d3a70811110512n5e485595of1851a1647ffea96@mail.gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <1254110628.20081111143519@gmail.com> <4165d3a70811110512n5e485595of1851a1647ffea96@mail.gmail.com> Message-ID: On Tue, 11 Nov 2008, Jefferson Heard wrote: > Actually, one language you mention there *is* worse than the others > for writing wrappable library code: C++. Admittedly, they've got a > Python interface now via boost, but the main problem with writing > wrappable C++ code is the template system and the inheritence systems > getting in the way. Symbol names aren't predictable and not > standardized, so it becomes impossible to write a portable system for > finding and binding to functions in a library. I've not yet found a > good way to do it in FFI code, and I would love to, as one library in > particular I hold near and dear -- OpenSceneGraph -- is entirely > written in C++. SWIG helps wrapping C++ libraries by providing C wrappers to C++ functions. However, as far as I know, templates cannot be wrapped as they are, but only instances of templates. Thus there is no wrapper to STL. From arnarbi at gmail.com Tue Nov 11 09:00:23 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Tue Nov 11 09:02:56 2008 Subject: [Haskell-cafe] Re: What *not* to use Haskell for In-Reply-To: References: <1226399902.6496.9.camel@rubix.office.last.fm> <1254110628.20081111143519@gmail.com> <4165d3a70811110512n5e485595of1851a1647ffea96@mail.gmail.com> Message-ID: <28012bc60811110600t9f09ba7h1769270c161ddb91@mail.gmail.com> On Tue, Nov 11, 2008 at 14:46, Henning Thielemann wrote: > SWIG helps wrapping C++ libraries by providing C wrappers to C++ functions. > However, as far as I know, templates cannot be wrapped as they are, but only > instances of templates. Thus there is no wrapper to STL. Maybe my understanding is a bit off, but isn't this to be expected? There's no way to compile a generic template to machine code, as template instantiation happens at source level in C++. cheers, Arnar From bulat.ziganshin at gmail.com Tue Nov 11 09:13:26 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 11 09:10:24 2008 Subject: [Haskell-cafe] Re: What *not* to use Haskell for In-Reply-To: <4165d3a70811110512n5e485595of1851a1647ffea96@mail.gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <1254110628.20081111143519@gmail.com> <4165d3a70811110512n5e485595of1851a1647ffea96@mail.gmail.com> Message-ID: <285618752.20081111171326@gmail.com> Hello Jefferson, Tuesday, November 11, 2008, 4:12:40 PM, you wrote: may be i doesn't understand something but why c#, java, delphi, visual basic, perl, python, ruby or even ml better than c++? symbol names in C++ are easily predictable with wrapper using extern "C". i think that you just not tried to write warppers to code in other languages - the same problems are everywhere > Actually, one language you mention there *is* worse than the others > for writing wrappable library code: C++. Admittedly, they've got a > Python interface now via boost, but the main problem with writing > wrappable C++ code is the template system and the inheritence systems > getting in the way. Symbol names aren't predictable and not > standardized, so it becomes impossible to write a portable system for > finding and binding to functions in a library. I've not yet found a > good way to do it in FFI code, and I would love to, as one library in > particular I hold near and dear -- OpenSceneGraph -- is entirely > written in C++. > -- Jeff > On Tue, Nov 11, 2008 at 6:35 AM, Bulat Ziganshin > wrote: >> Hello Mauricio, >> >> Tuesday, November 11, 2008, 2:26:21 PM, you wrote: >> >> imho, Haskell isn't worse here than any other compiled language - C++, >> ML, Eiffel and beter tnan Java or C#.every language has its own object >> model and GC. the only ay is to provide C-typed interfaces between >> languages (or use COM, IDL and other API-describing languages) >> >>> I think Haskell is not nice to write general purpouse libraries >>> that could be easily and completly wrapped by other languages. >>> You can wrap gtk, sqlite3, gsl, opengl etc., but you can't write >>> python bindings for Data.Graph. >> >>> But, then, if you claim there's nothing else Haskell can't do, >>> what do you need those bindings for ? :) >> >>> Best, >>> Mauricio >> >>>> Hi everyone >>>> >>>> So I should clarify I'm not a troll and do "see the Haskell light". But >>>> one thing I can never answer when preaching to others is "what does >>>> Haskell not do well?" >>>> >>>> Usually I'll avoid then question and explain that it is a 'complete' >>>> language and we do have more than enough libraries to make it useful and >>>> productive. But I'd be keen to know if people have any anecdotes, >>>> ideally ones which can subsequently be twisted into an argument for >>>> Haskell ;) >>>> >>>> Cheers, >>>> >>>> Dave >> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >> -- >> Best regards, >> Bulat mailto:Bulat.Ziganshin@gmail.com >> >> _______________________________________________ >> 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 robgreayer at yahoo.com Tue Nov 11 10:09:20 2008 From: robgreayer at yahoo.com (Robert Greayer) Date: Tue Nov 11 10:03:51 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <1226399902.6496.9.camel@rubix.office.last.fm> Message-ID: <476873.94567.qm@web65716.mail.ac4.yahoo.com> --- On Tue, 11/11/08, Dave Tapley wrote: > So I should clarify I'm not a troll and do "see > the Haskell light". But > one thing I can never answer when preaching to others is > "what does > Haskell not do well?" > 'Hard' real-time applications? I don't know that there couldn't be a 'real-time friendly' Haskell, but for some applications, the unpredictability (however slight) of when, for example, garbage collection happens, or how long it takes, is unacceptable. (Even the unpredictability of heap allocation/deallocation a la malloc/free is unacceptable for some real time apps). Haskell is in the same boat here with lots of other languages, of course. From pieter at laeremans.org Tue Nov 11 10:38:06 2008 From: pieter at laeremans.org (Pieter Laeremans) Date: Tue Nov 11 10:32:39 2008 Subject: [Haskell-cafe] ByteString/parsec Message-ID: HI, I want to efficiently parse a large collections of files. The files are in the format : example title TITLE author name AUTHOR some lines with summary here SUMMARY the real text TEXT a list of links LINKS I want to use "ByteString" here, but which library should I use to parse ? "attoparsec" or "bytestringparser", both export the same interface. When I use one of these I thaught it would be nice to write something like this : fileParser :: Parser Content fileParser = do title <- manyTill getInput (string . pack "\nTITLE\n") author <- manyTill getInput (string. pack "\nTITLE\n") .... return Content title author ... But this doesn't work. Even on a small example : parseTest (manyTill getInput (string $ pack "SPLIT") (pack "split the text at SPLIT part two") I get a stack overflow. Obviously I'm not understanding something here. Are there any good examples of open source projects which parse ByteString data ? thanks in advance, Pieter -- Pieter Laeremans "The future is here. It's just not evenly distributed yet." W. Gibson From Malcolm.Wallace at cs.york.ac.uk Tue Nov 11 10:54:47 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Nov 11 10:53:42 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <491969F4.6000300@jellybean.co.uk> References: <1226399902.6496.9.camel@rubix.office.last.fm> <491969F4.6000300@jellybean.co.uk> Message-ID: <20081111155447.43bd39cc.Malcolm.Wallace@cs.york.ac.uk> Jules Bean wrote: > GHC's scheduler lacks any hard timeliness guarantees. > > This is probably not a fundamental problem with haskell. It's a > problem with the compiler/RTS which we happen to be using. Actually, I would say it is much worse than that. It is not merely a question of implementation. We do not have _any_ predictable theory of resource usage (time, memory) for a lazy language. There is no analysis (yet) which can look at an arbitrary piece of Haskell code and tell you how long it will take to execute, or how much heap/stack it will eat. What is more, it is very hard to do that in a modular way. The execution time of lazy code is entirely dependent on its usage/demand context. So you can't just apply WCET to single functions, then combine the results. It's a question I'd love to be able to solve, but I note that those who are currently working on predictable execution of functional languages (e.g. the Hume project) have already ditched laziness in favour of eager execution. Regards, Malcolm From Christian.Maeder at dfki.de Tue Nov 11 11:13:50 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Nov 11 11:08:19 2008 Subject: [Haskell-cafe] Re: ByteString/parsec In-Reply-To: References: Message-ID: <4919AF3E.7070501@dfki.de> Pieter Laeremans wrote: > fileParser :: Parser Content > fileParser = do > title <- manyTill getInput (string . pack "\nTITLE\n") > author <- manyTill getInput (string. pack "\nTITLE\n") > .... > return Content title author ... > > But this doesn't work. "getInput" does not consume any input but just returns the remaining input. Therefore it is called infinitely often. If your input were String you could use "anyChar" instead. I don't know how to do it with ByteString (maybe parsec-3?). > I get a stack overflow. Obviously I'm not understanding something here. > Are there any good examples of open source projects which parse > ByteString data ? > > thanks in advance, Cheers Christian From agocorona at gmail.com Tue Nov 11 11:25:49 2008 From: agocorona at gmail.com (Alberto G. Corona ) Date: Tue Nov 11 11:20:21 2008 Subject: [Haskell-cafe] announce: Workflow-0.1 Message-ID: I needed to to define multiuser web workflows in the most transparent way. I wondered if a state monad could transparently bring automatic checkpointing of each action and automatic resume after failure. In this way a long living computation could be expressed in a single monadic computation. Additionally, for inter process communications, this package includes a primitive for activating a workflow whenever any action result meet certain condition. There are also primitives for start/restart processes, retrieval of intermediate results and unsafe IO actions inside the state monad... http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Workflow Cabal description: Transparent low level support (state logging, resume of the computation, wait for data condition) for long living, event driven processes. Workflow give the two first services to any monadic computation of type (a-> m a) usually m=IO f x >>=\x'-> g x' >>= \x''->... z by prefixing the user with the method "step": step f x >>= \x'-> step g x' >>= \x''->... This means that a workflow can be described with the familiar "do" notation. In principle, there is no other limitation on the syntax but the restriction (a -> m a): All computations consume and produce the same type of data. do notation is supported fully. Workflow export a few primitives that bring the following services: - transparent checkpointing of each step in permanent storage using TCache (step) - resume of the monadic computation at the last checkpoint after soft or hard interruption - use of versioning techniques for storing object changes (using RefSerialize) - retrieval of the object at any previous step - suspend the computation (waitFor) until the input object meet certain conditions. useful for inter-workflow comunications. At the end of the workflow all the intermediate data is erased. see demos and the header of Control.TCache for documentation. This is a piece of code is a loop that imput numbers (demo.hs). there is another process, that check the numbers entered and return Finish when match the desired number. that is detected by this thread and finalize. When number of tries are 9, The process finish, this is detected by the other process and finalizes also. That ilustrates the use of event handling (waitFor) and step execution. askNumbers name d = do step2 $ threadDelay 5000 -- wait for the other tread to process. r <- step (waitFor anything) d -- get the last value of the object with key "try-finish", to look for the other thread actions case r of Finish msg -> step2 $ print msg --the other thread sent a finalize response Try 9 num -> step1 $ return $ Finish "sorry, no more guesses" --send finalization to the wait thread _ -> do nd <- step (askNumber name) d askNumbers name nd where anything= \_-> True -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081111/778f6adc/attachment.htm From colin at colina.demon.co.uk Tue Nov 11 11:45:55 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Tue Nov 11 11:40:27 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? Message-ID: Is there a way to call Haskell code from other languages? I have looked on the wiki, and as far as I can see, it only talks about the other way round (when Haskell is the main program). -- Colin Adams Preston Lancashire From jake at pikewerks.com Tue Nov 11 11:51:53 2008 From: jake at pikewerks.com (Jake Mcarthur) Date: Tue Nov 11 11:46:25 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 11, 2008, at 10:45 AM, Colin Paul Adams wrote: > Is there a way to call Haskell code from other languages? I have > looked on > the wiki, and as far as I can see, it only talks about the other way > round (when Haskell is the main program). http://www.haskell.org/haskellwiki/GHC/Using_the_FFI#Calling_Haskell_from_C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkZuCkACgkQye5hVyvIUKk1pwCfRbVnERADZPygCNX2wjNkdQOC FXMAoKodV1TitVzr5ZJF/AUSmCXuRuKY =BUkK -----END PGP SIGNATURE----- From jake at pikewerks.com Tue Nov 11 11:53:14 2008 From: jake at pikewerks.com (Jake Mcarthur) Date: Tue Nov 11 11:47:44 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? In-Reply-To: References: Message-ID: <457DB857-8E23-4DF3-964E-D54183B732EA@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Actually, that's not the whole story. I didn't realize until I sent it. There does exist good documentation for this, I promise. - - Jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkZuHoACgkQye5hVyvIUKnGeACfZN+9nNy+nGvQHDsG1FrI4Puu Zw0AmgKK0WOYTjWWeQX93rrnSJApG0pa =Vazy -----END PGP SIGNATURE----- From donn at avvanta.com Tue Nov 11 11:59:21 2008 From: donn at avvanta.com (Donn Cave) Date: Tue Nov 11 11:53:53 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? Message-ID: <20081111165921.6EC54F395B@mail.avvanta.com> Quoth Colin Paul Adams : | Is there a way to call Haskell code from other languages? I have looked on | the wiki, and as far as I can see, it only talks about the other way | round (when Haskell is the main program). There sure is a way to call from other languages - cf. "foreign export" - but don't know how hard it would be to make Haskell live without its "main", which performs a lot of runtime initialization. For me (with nhc98) it's a lot easier to use a Haskell "main" that's just a brief wrapper: module Main (main) where import NHC.FFI foreign import ccall "cmain" cmain :: IO () main = cmain (... where "cmain" is an external entry point in the C code, which can then call Haskell as required.) Donn From colin at colina.demon.co.uk Tue Nov 11 12:09:09 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Tue Nov 11 12:03:42 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? In-Reply-To: <457DB857-8E23-4DF3-964E-D54183B732EA@pikewerks.com> (Jake Mcarthur's message of "Tue\, 11 Nov 2008 10\:53\:14 -0600") References: <457DB857-8E23-4DF3-964E-D54183B732EA@pikewerks.com> Message-ID: >>>>> "Jake" == Jake Mcarthur writes: Jake> Actually, that's not the whole story. I didn't realize until Jake> I sent it. There does exist good documentation for this, I Jake> promise. Good. Let me know where it is when you track it down. The link you pointed me too doesn't seem to address my question directly. Also, it only talks about C. If I want to call Haskell (and I do, perhaps) from another garbage-collected language (Eiffel, in particular) using C as the mutually understood language, am I not going to run into big problems? -- Colin Adams Preston Lancashire From bulat.ziganshin at gmail.com Tue Nov 11 12:21:39 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 11 12:16:18 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? In-Reply-To: References: <457DB857-8E23-4DF3-964E-D54183B732EA@pikewerks.com> Message-ID: <1865538746.20081111202139@gmail.com> Hello Colin, Tuesday, November 11, 2008, 8:09:09 PM, you wrote: > If I want to call Haskell (and I do, perhaps) from another > garbage-collected language (Eiffel, in particular) using C as the > mutually understood language, am I not going to run into big problems? of course not. there will be two independent heaps. of course you can't directly send pointers to gc-collected structures between two languages, they should be converted through buffers in C world (i.e. malloced ones) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jules at jellybean.co.uk Tue Nov 11 12:25:16 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Tue Nov 11 12:19:49 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <20081111155447.43bd39cc.Malcolm.Wallace@cs.york.ac.uk> References: <1226399902.6496.9.camel@rubix.office.last.fm> <491969F4.6000300@jellybean.co.uk> <20081111155447.43bd39cc.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <4919BFFC.5080800@jellybean.co.uk> Malcolm Wallace wrote: > Jules Bean wrote: > >> GHC's scheduler lacks any hard timeliness guarantees. >> >> This is probably not a fundamental problem with haskell. It's a >> problem with the compiler/RTS which we happen to be using. > > Actually, I would say it is much worse than that. It is not merely a > question of implementation. We do not have _any_ predictable theory of > resource usage (time, memory) for a lazy language. There is no analysis > (yet) which can look at an arbitrary piece of Haskell code and tell you > how long it will take to execute, or how much heap/stack it will eat. > What is more, it is very hard to do that in a modular way. The > execution time of lazy code is entirely dependent on its usage/demand > context. So you can't just apply WCET to single functions, then combine > the results. That's true but I'm not sure you need to solve that (hard, interesting) problem just to get *some* kind of timeliness guarantees. For example the guarantee that a thread is woken up within 10us of the MVar it was sleeping on being filled doesn't require you to solve the whole problem. It requires you to be able to bound GC time, or preempt the GC, but that's feasible isn't it? Then there is the possibility of a strict DSL (probably but not necessarily a Monad) within haskell which has strong timeliness guarantees. Jules From peter.padawitz at udo.edu Tue Nov 11 12:49:11 2008 From: peter.padawitz at udo.edu (Peter Padawitz) Date: Tue Nov 11 12:43:45 2008 Subject: [Haskell-cafe] compilation question Message-ID: <4919C597.6020607@udo.edu> At first a type of arithmetic expressions and its generic evaluator: data Expr = Con Int | Var String | Sum [Expr] | Prod [Expr] | Expr :- Expr | Int :* Expr | Expr :^ Int data ExprAlg a = ExprAlg {con :: Int -> a, var :: String -> a, sum_ :: [a] -> a, prod :: [a] -> a, sub :: a -> a -> a, scal :: Int -> a -> a, expo :: a -> Int -> a} eval :: ExprAlg a -> Expr -> a eval alg (Con i) = con alg i eval alg (Var x) = var alg x eval alg (Sum es) = sum_ alg (map (eval alg) es) eval alg (Prod es) = prod alg (map (eval alg) es) eval alg (e :- e') = sub alg (eval alg e) (eval alg e') eval alg (n :* e) = scal alg n (eval alg e) eval alg (e :^ n) = expo alg (eval alg e) n Secondly, a procedural version of eval (in fact based on continuations): data Id a = Id {out :: a} deriving Show instance Monad Id where (>>=) m = ($ out m); return = Id peval :: ExprAlg a -> Expr -> Id a peval alg (Con i) = return (con alg i) peval alg (Var x) = return (var alg x) peval alg (Sum es) = do as <- mapM (peval alg) es; return (sum_ alg as) peval alg (Prod es) = do as <- mapM (peval alg) es; return (prod alg as) peval alg (e :- e') = do a <- peval alg e; b <- peval alg e'; return (sub alg a b) peval alg (n :* e) = do a <- peval alg e; return (scal alg n a) peval alg (e :^ n) = do a <- peval alg e; return (expo alg a n) My question: Is peval less time- or space-consuming than eval? Or would ghc, hugs et al. optimize eval towards peval by themselves? Peter From neil.mitchell.2 at credit-suisse.com Tue Nov 11 12:54:29 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Tue Nov 11 12:49:56 2008 Subject: [Haskell-cafe] compilation question In-Reply-To: <4919C597.6020607@udo.edu> References: <4919C597.6020607@udo.edu> Message-ID: Hi The one way to test this is to benchmark, everything else will just be peoples random guesses. As for my random guess, eval should be significantly faster than peval in Hugs, and probably slightly faster than peval in GHC. I don't see why you think peval is efficient - monads /= efficiency, they merely are an extra layer over standard evaluation. If you use the IO monad and some careful annotations you could hope to draw with eval, but just accept the beauty that is pure functional programming and smile :-) Thanks Neil > -----Original Message----- > From: haskell-cafe-bounces@haskell.org > [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Peter Padawitz > Sent: 11 November 2008 5:49 pm > To: haskell-cafe@haskell.org > Cc: Hubert Wagner > Subject: [Haskell-cafe] compilation question > > At first a type of arithmetic expressions and its generic evaluator: > > data Expr = Con Int | Var String | Sum [Expr] | Prod [Expr] | Expr :- > Expr | > Int :* Expr | Expr :^ Int > > data ExprAlg a = ExprAlg {con :: Int -> a, var :: String -> > a, sum_ :: > [a] -> a, > prod :: [a] -> a, sub :: a -> a -> a, > scal :: Int -> a -> a, expo :: a -> Int -> a} > > eval :: ExprAlg a -> Expr -> a > eval alg (Con i) = con alg i > eval alg (Var x) = var alg x > eval alg (Sum es) = sum_ alg (map (eval alg) es) > eval alg (Prod es) = prod alg (map (eval alg) es) > eval alg (e :- e') = sub alg (eval alg e) (eval alg e') > eval alg (n :* e) = scal alg n (eval alg e) > eval alg (e :^ n) = expo alg (eval alg e) n > > Secondly, a procedural version of eval (in fact based on > continuations): > > data Id a = Id {out :: a} deriving Show > > instance Monad Id where (>>=) m = ($ out m); return = Id > > peval :: ExprAlg a -> Expr -> Id a > peval alg (Con i) = return (con alg i) > peval alg (Var x) = return (var alg x) > peval alg (Sum es) = do as <- mapM (peval alg) es; return > (sum_ alg as) > peval alg (Prod es) = do as <- mapM (peval alg) es; return > (prod alg as) > peval alg (e :- e') = do a <- peval alg e; b <- peval alg e'; return > (sub alg a b) > peval alg (n :* e) = do a <- peval alg e; return (scal alg n a) > peval alg (e :^ n) = do a <- peval alg e; return (expo alg a n) > > My question: Is peval less time- or space-consuming than > eval? Or would > ghc, hugs et al. optimize eval towards peval by themselves? > > Peter > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From huschi at gmx.org Tue Nov 11 13:28:49 2008 From: huschi at gmx.org (Martin Huschenbett) Date: Tue Nov 11 13:23:22 2008 Subject: [Haskell-cafe] Problem installing curl Message-ID: <4919CEE1.50002@gmx.org> Hi all, when I try to install curl (needed for hxt) using "cabal install curl" I alwas get the following error message: Resolving dependencies... 'curl-1.3.2.1' is cached. Configuring curl-1.3.2.1... cabal: Error: some packages failed to install: curl-1.3.2.1 failed during the configure step. The exception was: sh: runGenProcess: does not exist (No such file or directory) I don't know what to do here. Can anybody help me please? I'm using the brand new GHC 6.10.1 on Windows Vista. Best regards, Martin. From allbery at ece.cmu.edu Tue Nov 11 13:34:08 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Nov 11 13:28:40 2008 Subject: [Haskell-cafe] compiling haskell-src-exts in 6.10 In-Reply-To: <7b92c2840811110420i370e124dl616373df08373d7e@mail.gmail.com> References: <7b92c2840811110420i370e124dl616373df08373d7e@mail.gmail.com> Message-ID: <3EC5F5DE-D0EE-40C9-8989-CAB205F8CEAB@ece.cmu.edu> On 2008 Nov 11, at 7:20, Hugo Pacheco wrote: > When installing package haskell-src-exts via cabal install, I get > the error > > Language/Haskell/Exts/Syntax.hs:102:7: > Could not find module `Data.Data': > it is a member of package base, which is hidden > > > However, when manually installing > > runhaskell Setup.hs configure/build/install > > It works fine > Somehow package base is not available in cabal.. don't know why. I think what this really means is that "cabal install" is using base-3 whereas direct installation is using base-4, or vice versa. dcoutts or the haskell-src-exts maintainer would have to tell you what to do about it though. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081111/64d96238/attachment.htm From derek.a.elkins at gmail.com Tue Nov 11 13:35:05 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Nov 11 13:29:42 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? In-Reply-To: References: <457DB857-8E23-4DF3-964E-D54183B732EA@pikewerks.com> Message-ID: <1226428505.12478.3.camel@derek-laptop> On Tue, 2008-11-11 at 17:09 +0000, Colin Paul Adams wrote: > >>>>> "Jake" == Jake Mcarthur writes: > > Jake> Actually, that's not the whole story. I didn't realize until > Jake> I sent it. There does exist good documentation for this, I > Jake> promise. > > Good. Let me know where it is when you track it down. > > The link you pointed me too doesn't seem to address my question > directly. Also, it only talks about C. > > If I want to call Haskell (and I do, perhaps) from another > garbage-collected language (Eiffel, in particular) using C as the > mutually understood language, am I not going to run into big problems? Read the FFI Report. It is relatively readable and comprehensive. http://www.cse.unsw.edu.au/~chak/haskell/ffi/ And yes, you will have to use C as an intermediary, though you may not have to actually write any C. You simply expose the Haskell functions in whatever form the other language expects. You'll almost certainly have to write marshalling code of some sort. From derek.a.elkins at gmail.com Tue Nov 11 13:38:28 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Nov 11 13:33:06 2008 Subject: [Haskell-cafe] compilation question In-Reply-To: <4919C597.6020607@udo.edu> References: <4919C597.6020607@udo.edu> Message-ID: <1226428708.12478.7.camel@derek-laptop> On Tue, 2008-11-11 at 18:49 +0100, Peter Padawitz wrote: > At first a type of arithmetic expressions and its generic evaluator: > > data Expr = Con Int | Var String | Sum [Expr] | Prod [Expr] | Expr :- > Expr | > Int :* Expr | Expr :^ Int > > data ExprAlg a = ExprAlg {con :: Int -> a, var :: String -> a, sum_ :: > [a] -> a, > prod :: [a] -> a, sub :: a -> a -> a, > scal :: Int -> a -> a, expo :: a -> Int -> a} > > eval :: ExprAlg a -> Expr -> a > eval alg (Con i) = con alg i > eval alg (Var x) = var alg x > eval alg (Sum es) = sum_ alg (map (eval alg) es) > eval alg (Prod es) = prod alg (map (eval alg) es) > eval alg (e :- e') = sub alg (eval alg e) (eval alg e') > eval alg (n :* e) = scal alg n (eval alg e) > eval alg (e :^ n) = expo alg (eval alg e) n > > Secondly, a procedural version of eval (in fact based on continuations): > > data Id a = Id {out :: a} deriving Show > > instance Monad Id where (>>=) m = ($ out m); return = Id > > peval :: ExprAlg a -> Expr -> Id a > peval alg (Con i) = return (con alg i) > peval alg (Var x) = return (var alg x) > peval alg (Sum es) = do as <- mapM (peval alg) es; return (sum_ alg as) > peval alg (Prod es) = do as <- mapM (peval alg) es; return (prod alg as) > peval alg (e :- e') = do a <- peval alg e; b <- peval alg e'; return > (sub alg a b) > peval alg (n :* e) = do a <- peval alg e; return (scal alg n a) > peval alg (e :^ n) = do a <- peval alg e; return (expo alg a n) > > My question: Is peval less time- or space-consuming than eval? Or would > ghc, hugs et al. optimize eval towards peval by themselves? peval is not based on continuations. As you state, you are using the Id monad. (>>=) is just flip ($). Unless GHC has some trouble seeing through the Monad instance, it should simply inline the latter to the former since they are the exact same code. From dons at galois.com Tue Nov 11 13:49:13 2008 From: dons at galois.com (Don Stewart) Date: Tue Nov 11 13:43:48 2008 Subject: [Haskell-cafe] Problem installing curl In-Reply-To: <4919CEE1.50002@gmx.org> References: <4919CEE1.50002@gmx.org> Message-ID: <20081111184913.GF28091@scytale.galois.com> huschi: > Hi all, > > when I try to install curl (needed for hxt) using "cabal install curl" I > alwas get the following error message: > > > Resolving dependencies... > 'curl-1.3.2.1' is cached. > Configuring curl-1.3.2.1... > cabal: Error: some packages failed to install: > curl-1.3.2.1 failed during the configure step. The exception was: > sh: runGenProcess: does not exist (No such file or directory) > > > I don't know what to do here. Can anybody help me please? > > I'm using the brand new GHC 6.10.1 on Windows Vista. > > Best regards, > Do you have the curl C library installed? Either way, that error message from Cabal isn't very good. Duncan? -- Don From chad.scherrer at pnl.gov Tue Nov 11 14:23:09 2008 From: chad.scherrer at pnl.gov (Chad Scherrer) Date: Tue Nov 11 14:19:36 2008 Subject: [Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays Message-ID: Hello cafe, I've hit a bit of a monadic snag here... I'm scanning a big file, building a table of statistics. I end up with something like IO (IntMap (IOUArray Int Double)) Once I've read in the whole file and built my statistics, I don't need any more updates, so I'd like to do something like IntMap (IOUArray Int Double) -> IO (IntMap (UArray Int Double)), using unsafeFreeze. I'm getting stuck here, since the IntMap library is not so monad-friendly. I could rebuild the whole thing using sequence and lists, but the table is pretty big (4.5 million keys on a first run), so I'd prefer to avoid that. Any ideas? BTW, I probably "should" be using ST for this, but I hit the usual "type s escapes" irritation and gave up. If that would work more easily, that would be fine with me too. Thanks! Chad Scherrer From dons at galois.com Tue Nov 11 14:28:23 2008 From: dons at galois.com (Don Stewart) Date: Tue Nov 11 14:22:53 2008 Subject: [Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays In-Reply-To: References: Message-ID: <20081111192823.GL28091@scytale.galois.com> chad.scherrer: > Hello cafe, > > I've hit a bit of a monadic snag here... > > I'm scanning a big file, building a table of statistics. I end up with > something like > > IO (IntMap (IOUArray Int Double)) > > Once I've read in the whole file and built my statistics, I don't need > any more updates, so I'd like to do something like > > IntMap (IOUArray Int Double) -> IO (IntMap (UArray Int Double)), > > using unsafeFreeze. I'm getting stuck here, since the IntMap library > is not so monad-friendly. Hmm. So you'd need to construct a new IntMap, made by fmap'ping unsafeFreeze over each element of the old map. -- Don From jgoerzen at complete.org Tue Nov 11 14:31:06 2008 From: jgoerzen at complete.org (John Goerzen) Date: Tue Nov 11 14:25:41 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? In-Reply-To: <1226428505.12478.3.camel@derek-laptop> References: <457DB857-8E23-4DF3-964E-D54183B732EA@pikewerks.com> <1226428505.12478.3.camel@derek-laptop> Message-ID: <20081111193106.GA23562@hustlerturf.com> On Tue, Nov 11, 2008 at 12:35:05PM -0600, Derek Elkins wrote: > On Tue, 2008-11-11 at 17:09 +0000, Colin Paul Adams wrote: > > >>>>> "Jake" == Jake Mcarthur writes: > > > > Jake> Actually, that's not the whole story. I didn't realize until > > Jake> I sent it. There does exist good documentation for this, I > > Jake> promise. > > > > Good. Let me know where it is when you track it down. > > > > The link you pointed me too doesn't seem to address my question > > directly. Also, it only talks about C. > > > > If I want to call Haskell (and I do, perhaps) from another > > garbage-collected language (Eiffel, in particular) using C as the > > mutually understood language, am I not going to run into big problems? > > Read the FFI Report. It is relatively readable and comprehensive. > http://www.cse.unsw.edu.au/~chak/haskell/ffi/ > > And yes, you will have to use C as an intermediary, though you may not > have to actually write any C. You simply expose the Haskell functions > in whatever form the other language expects. You'll almost certainly > have to write marshalling code of some sort. I often like to look at these situations as an opportunity to introduce modularity and piping. Do you really need them running in the same address space? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From duncan.coutts at worc.ox.ac.uk Tue Nov 11 14:31:44 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Nov 11 14:26:21 2008 Subject: [Haskell-cafe] Problem installing curl In-Reply-To: <20081111184913.GF28091@scytale.galois.com> References: <4919CEE1.50002@gmx.org> <20081111184913.GF28091@scytale.galois.com> Message-ID: <1226431904.17214.204.camel@localhost> On Tue, 2008-11-11 at 10:49 -0800, Don Stewart wrote: > > curl-1.3.2.1 failed during the configure step. The exception was: > > sh: runGenProcess: does not exist (No such file or directory) > > > > I don't know what to do here. Can anybody help me please? > > > > I'm using the brand new GHC 6.10.1 on Windows Vista. > > > > Best regards, > > > > Do you have the curl C library installed? The first problem is that curl uses a configure script and that needs 'sh' which needs mingw+msys or cygwin. That's what the error message is obliquely reporting. After that the next problem will be having the curl C lib installed. > Either way, that error message from Cabal isn't very good. Duncan? Filed: http://hackage.haskell.org/trac/hackage/ticket/403 It should be easy to fix. It's a nice simple bug for some new Cabal contributor. Speaking of Cabal contributors, we're a little short of them at the moment. I welcome people to check out our list of easy tickets: http://hackage.haskell.org/trac/hackage/report/13 And to see the guide to the code base: http://hackage.haskell.org/trac/hackage/wiki/SourceGuide Duncan From dons at galois.com Tue Nov 11 14:38:23 2008 From: dons at galois.com (Don Stewart) Date: Tue Nov 11 14:33:18 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? In-Reply-To: References: Message-ID: <20081111193823.GN28091@scytale.galois.com> colin: > Is there a way to call Haskell code from other languages? I have looked on > the wiki, and as far as I can see, it only talks about the other way > round (when Haskell is the main program). http://haskell.org/haskellwiki/Calling_Haskell_from_C Cheers, Don From chad.scherrer at pnl.gov Tue Nov 11 14:39:53 2008 From: chad.scherrer at pnl.gov (Chad Scherrer) Date: Tue Nov 11 14:34:31 2008 Subject: [Haskell-cafe] Re: mapping unfreeze over an IntMap of IOUArrays References: <20081111192823.GL28091@scytale.galois.com> Message-ID: Don Stewart galois.com> writes: > Hmm. So you'd need to construct a new IntMap, made by fmap'ping > unsafeFreeze over each element of the old map. I guess if we had a Traversable instance for Data.IntMap things would be just fine. Would this be a bad thing in any way? Chad From dons at galois.com Tue Nov 11 14:39:37 2008 From: dons at galois.com (Don Stewart) Date: Tue Nov 11 14:34:56 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? In-Reply-To: References: <457DB857-8E23-4DF3-964E-D54183B732EA@pikewerks.com> Message-ID: <20081111193937.GO28091@scytale.galois.com> colin: > >>>>> "Jake" == Jake Mcarthur writes: > > Jake> Actually, that's not the whole story. I didn't realize until > Jake> I sent it. There does exist good documentation for this, I > Jake> promise. > > Good. Let me know where it is when you track it down. > > The link you pointed me too doesn't seem to address my question > directly. Also, it only talks about C. > > If I want to call Haskell (and I do, perhaps) from another > garbage-collected language (Eiffel, in particular) using C as the > mutually understood language, am I not going to run into big problems? No, you can manage objects via e.g. ForeignPtr's. The community has a whole has done bridges between Haskell and pretty much anything you care to name, via the C FFI. Just depends on how well you understand the memory management models of both players. -- Don From colin at colina.demon.co.uk Tue Nov 11 15:07:55 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Tue Nov 11 15:02:29 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? In-Reply-To: <20081111193106.GA23562@hustlerturf.com> (John Goerzen's message of "Tue\, 11 Nov 2008 13\:31\:06 -0600") References: <457DB857-8E23-4DF3-964E-D54183B732EA@pikewerks.com> <1226428505.12478.3.camel@derek-laptop> <20081111193106.GA23562@hustlerturf.com> Message-ID: >>>>> "John" == John Goerzen writes: >> Read the FFI Report. It is relatively readable and >> comprehensive. http://www.cse.unsw.edu.au/~chak/haskell/ffi/ >> >> And yes, you will have to use C as an intermediary, though you >> may not have to actually write any C. You simply expose the >> Haskell functions in whatever form the other language expects. >> You'll almost certainly have to write marshalling code of some >> sort. John> I often like to look at these situations as an opportunity John> to introduce modularity and piping. Do you really need them John> running in the same address space? Good point. And thanks everyone for your help. I have enough to go on now. -- Colin Adams Preston Lancashire From fegaras at cse.uta.edu Tue Nov 11 15:16:21 2008 From: fegaras at cse.uta.edu (Leonidas Fegaras) Date: Tue Nov 11 15:10:53 2008 Subject: [Haskell-cafe] problem with boolean splicing in templates in ghc 6.10.1 Message-ID: <1226434581.17406.13.camel@functor.uta.edu> Seems that boolean splicing in haskell templates in ghc 6.10.1 does not work correctly. If you do: $((\b -> [| b |]) True) you get the error: Can't find interface-file declaration for data constructor GHC.Base.True Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error It seems that GHC.Base.True is now GHC.Bool.True, but the splicing code still generates the former. Leonidas Fegaras From bulat.ziganshin at gmail.com Tue Nov 11 15:25:07 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 11 15:21:58 2008 Subject: [Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays In-Reply-To: References: Message-ID: <182039970.20081111232507@gmail.com> Hello Chad, Tuesday, November 11, 2008, 10:23:09 PM, you wrote: > using unsafeFreeze. I'm getting stuck here, since the IntMap library is not so > monad-friendly. Data.Hashtable is -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ross at soi.city.ac.uk Tue Nov 11 15:31:48 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Nov 11 15:26:59 2008 Subject: [Haskell-cafe] Re: mapping unfreeze over an IntMap of IOUArrays In-Reply-To: References: <20081111192823.GL28091@scytale.galois.com> Message-ID: <20081111203147.GA7297@soi.city.ac.uk> On Tue, Nov 11, 2008 at 07:39:53PM +0000, Chad Scherrer wrote: > Don Stewart galois.com> writes: > > Hmm. So you'd need to construct a new IntMap, made by fmap'ping > > unsafeFreeze over each element of the old map. > > I guess if we had a Traversable instance for Data.IntMap things would be just > fine. Would this be a bad thing in any way? I don't think so. It's a straightforward instance, and its omission was an oversight. From Chad.Scherrer at pnl.gov Tue Nov 11 15:43:03 2008 From: Chad.Scherrer at pnl.gov (Scherrer, Chad) Date: Tue Nov 11 15:37:35 2008 Subject: [Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays In-Reply-To: <182039970.20081111232507@gmail.com> References: <182039970.20081111232507@gmail.com> Message-ID: <64F04C9398A52E43B208634452B7D00B0407B3AA@EMAIL01.pnl.gov> Bulat wrote: > Hello Chad, > > Tuesday, November 11, 2008, 10:23:09 PM, you wrote: > > using unsafeFreeze. I'm getting stuck here, since the > IntMap library > > is not so monad-friendly. > > Data.Hashtable is Well, I need mutable update for a while... after that, I prefer a pure interface, which is why I'm trying to freeze all the values. Anyway, I haven't used hashtables in Haskell, but I vaguely remember some discussion about them being really slow. Is this no longer the case? I guess if I really need to go this route I could try out HsJudy or something. Thanks, Chad From alexey.v.romanov at gmail.com Tue Nov 11 15:45:15 2008 From: alexey.v.romanov at gmail.com (Alexey Romanov) Date: Tue Nov 11 15:39:45 2008 Subject: [Haskell-cafe] Compilation issue with GHC 6.10.1 on Vista Message-ID: <2ec755810811111245t630fe0e1udab1cae3b3eaa749@mail.gmail.com> I'm trying to update FreshLib to work with the current GHC version. Now it works fine in GHCi, but trying to compile with ghc --make gives this result: [1 of 5] Compiling NominalBase ( NominalBase.hs, NominalBase.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package base-3.0.3.0 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package syb-with-class-0.4 ... linking ... done. C:\Users\Alexey\AppData\Local\Temp\/ghc1892_0/ghc1892_0.s: Assembler messages: C:\Users\Alexey\AppData\Local\Temp\/ghc1892_0/ghc1892_0.s:557: Error: symbol `_N ominalBase_zdgtoName_closure' is already defined C:\Users\Alexey\AppData\Local\Temp\/ghc1892_0/ghc1892_0.s:585: Error: symbol `_N ominalBase_zdgtoName_info' is already defined C:\Users\Alexey\AppData\Local\Temp\/ghc1892_0/ghc1892_0.s:637: Error: symbol `_N ominalBase_zdgfromName_closure' is already defined C:\Users\Alexey\AppData\Local\Temp\/ghc1892_0/ghc1892_0.s:665: Error: symbol `_N ominalBase_zdgfromName_info' is already defined Yours, Alexey Romanov From bulat.ziganshin at gmail.com Tue Nov 11 16:09:51 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 11 16:14:30 2008 Subject: [Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays In-Reply-To: References: <182039970.20081111232507@gmail.com> <64F04C9398A52E43B208634452B7D00B0407B3AA@EMAIL01.pnl.gov> Message-ID: <14010527201.20081112000951@gmail.com> Hello Max, Tuesday, November 11, 2008, 11:50:28 PM, you wrote: btw, i made here some time ago proposal about pure hashtables implented over a pure arrays (via accumArray operaion). may be it is somewhat helpful for you >>> > using unsafeFreeze. I'm getting stuck here, since the >>> IntMap library >>> > is not so monad-friendly. >>> >>> Data.Hashtable is >> >> Well, I need mutable update for a while... after that, I prefer a pure >> interface, which is why I'm trying to freeze all the values. > Is there any reason why an immutable Hashtable shouldn't be > implemented, with a pure interface, such that hashtables can be > (unsafe)Freezed into immutable hashtables? Would this be useful? > --Max -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From consalus at gmail.com Tue Nov 11 16:49:00 2008 From: consalus at gmail.com (Kyle Consalus) Date: Tue Nov 11 16:43:32 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <1226399902.6496.9.camel@rubix.office.last.fm> References: <1226399902.6496.9.camel@rubix.office.last.fm> Message-ID: <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley wrote: > Hi everyone > > So I should clarify I'm not a troll and do "see the Haskell light". But > one thing I can never answer when preaching to others is "what does > Haskell not do well?" > > Usually I'll avoid then question and explain that it is a 'complete' > language and we do have more than enough libraries to make it useful and > productive. But I'd be keen to know if people have any anecdotes, > ideally ones which can subsequently be twisted into an argument for > Haskell ;) > > Cheers, > > Dave > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > I think some would disagree with me, but I would advise against using haskell for a task that necessarily requires a lot of mutable state and IO and for which serious performance is a big factor. I'm not talking about stuff that can be approximated by zippers and whatnot, but rather situations where IORefs abound and data has identity. Haskell can quite capably do mutable state and IO, but if your task is all mutable state and IO, I'd lean toward a language that makes it easier (OCaml, perhaps). Also, I think there are some tasks which are more easily coded using an OO approach, and while this can be done in Haskell, I tend not to think it is worth the effort. I've worked multiple projects in which big hierarchies of business objects were used, and it had to be easily to add new subclasses with minor variation and to treat any as their parent. Considered by many in FP community to be bad style, but I've never seen the equivalent implemented in any other way effectively. Haskell's record system gets in the way, as does the (as perceived by me) esotericism of existential types. Oh, also, any task that requires a good hash table. :-P Mind you, Haskell is my first choice for a leisure project and I think it is an excellent choice for quite a few tasks and still capable of what I list above, just not in my opinion the best choice. From dons at galois.com Tue Nov 11 16:51:10 2008 From: dons at galois.com (Don Stewart) Date: Tue Nov 11 16:45:43 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> Message-ID: <20081111215110.GQ28091@scytale.galois.com> consalus: > On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley wrote: > > Hi everyone > > > > So I should clarify I'm not a troll and do "see the Haskell light". But > > one thing I can never answer when preaching to others is "what does > > Haskell not do well?" > > > > Usually I'll avoid then question and explain that it is a 'complete' > > language and we do have more than enough libraries to make it useful and > > productive. But I'd be keen to know if people have any anecdotes, > > ideally ones which can subsequently be twisted into an argument for > > Haskell ;) > > > > Cheers, > > > > Dave > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > I think some would disagree with me, but I would advise against using > haskell for a task that necessarily requires a lot of mutable state > and IO and for which serious performance is a big factor. I'm not > talking about stuff that can be approximated by zippers and whatnot, > but rather situations where IORefs abound and data has identity. > Haskell can quite capably do mutable state and IO, but if your task is > all mutable state and IO, I'd lean toward a language that makes it > easier (OCaml, perhaps). Do you have an example of a mutable state/ IO bound application, like, hmm, a window manager or a revision control system or a file system...? -- Don From dons at galois.com Tue Nov 11 16:51:33 2008 From: dons at galois.com (Don Stewart) Date: Tue Nov 11 16:46:04 2008 Subject: [Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays In-Reply-To: <14010527201.20081112000951@gmail.com> References: <182039970.20081111232507@gmail.com> <64F04C9398A52E43B208634452B7D00B0407B3AA@EMAIL01.pnl.gov> <14010527201.20081112000951@gmail.com> Message-ID: <20081111215133.GR28091@scytale.galois.com> bulat.ziganshin: > Hello Max, > > Tuesday, November 11, 2008, 11:50:28 PM, you wrote: > > btw, i made here some time ago proposal about pure hashtables > implented over a pure arrays (via accumArray operaion). may be it is > somewhat helpful for you Did you end up implementing this? -- Don From chad.scherrer at pnl.gov Tue Nov 11 17:18:47 2008 From: chad.scherrer at pnl.gov (Chad Scherrer) Date: Tue Nov 11 17:13:33 2008 Subject: [Haskell-cafe] Re: mapping unfreeze over an IntMap of IOUArrays References: <20081111192823.GL28091@scytale.galois.com> Message-ID: Don Stewart galois.com> writes: > Hmm. So you'd need to construct a new IntMap, made by fmap'ping > unsafeFreeze over each element of the old map. > For now I'll just do IntMap.map (unsafePerformIO . unsafeFreeze) Hopefully this won't come back to bite me.... Thanks! Chad From bulat.ziganshin at gmail.com Tue Nov 11 17:14:32 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 11 17:14:39 2008 Subject: [Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays In-Reply-To: <20081111215133.GR28091@scytale.galois.com> References: <182039970.20081111232507@gmail.com> <64F04C9398A52E43B208634452B7D00B0407B3AA@EMAIL01.pnl.gov> <14010527201.20081112000951@gmail.com> <20081111215133.GR28091@scytale.galois.com> Message-ID: <1047886631.20081112011432@gmail.com> Hello Don, Wednesday, November 12, 2008, 12:51:33 AM, you wrote: >> btw, i made here some time ago proposal about pure hashtables > Did you end up implementing this? yes, i have published here all the 10 lines of implementation :))) citing letter to you: actually, writing HT module from scratch is very easy - all we need is a prime searching function (in order to establish array size). everything else: data HT a b = HT (a->Int) (Array Int [(a,b)]) -- size is the size of array (we implent closed hash) -- hash is the hash function (a->Int) -- list is assoclist of items to put in hash create size hash list = HT hashfunc (accumArray (flip (:)) [] (0, arrsize-1) (map (\(a,b) -> (hashfunc a,b)) list) ) where arrsize = head$ filter (>size)$ iterate (\x->3*x+1) 1 hashfunc a = hash a `mod` arrsize lookup a (HT hash arr) = List.lookup a (arr!hash a) example: main = do let assoclist = [("one", 1), ("two", 2), ("three", 3)] hash = HT.create 10 Data.HashTable.hashString assoclist print (HT.lookup "one" hash) print (HT.lookup "zero" hash) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Tue Nov 11 17:21:18 2008 From: dons at galois.com (Don Stewart) Date: Tue Nov 11 17:15:52 2008 Subject: [Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays In-Reply-To: <1047886631.20081112011432@gmail.com> References: <182039970.20081111232507@gmail.com> <64F04C9398A52E43B208634452B7D00B0407B3AA@EMAIL01.pnl.gov> <14010527201.20081112000951@gmail.com> <20081111215133.GR28091@scytale.galois.com> <1047886631.20081112011432@gmail.com> Message-ID: <20081111222118.GT28091@scytale.galois.com> bulat.ziganshin: > Hello Don, > > Wednesday, November 12, 2008, 12:51:33 AM, you wrote: > > >> btw, i made here some time ago proposal about pure hashtables > > > Did you end up implementing this? > > yes, i have published here all the 10 lines of implementation :))) > > citing letter to you: > > actually, writing HT module from scratch is > very easy - all we need is a prime searching function (in order to > establish array size). everything else: > > data HT a b = HT (a->Int) (Array Int [(a,b)]) > > -- size is the size of array (we implent closed hash) > -- hash is the hash function (a->Int) > -- list is assoclist of items to put in hash > create size hash list = HT hashfunc > (accumArray (flip (:)) > [] > (0, arrsize-1) > (map (\(a,b) -> (hashfunc a,b)) list) > ) > > where arrsize = head$ filter (>size)$ iterate (\x->3*x+1) 1 > hashfunc a = hash a `mod` arrsize > > > lookup a (HT hash arr) = List.lookup a (arr!hash a) > > > example: > > main = do let assoclist = [("one", 1), ("two", 2), ("three", 3)] > hash = HT.create 10 Data.HashTable.hashString assoclist > print (HT.lookup "one" hash) > print (HT.lookup "zero" hash) > > If this structure is useful, you should release it on Hackage. You've not tested the performance though, I imagine, versus say, hasing into an IntMap? -- Don From bulat.ziganshin at gmail.com Tue Nov 11 17:20:32 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 11 17:16:25 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <20081111215110.GQ28091@scytale.galois.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com> Message-ID: <1179077088.20081112012032@gmail.com> Hello Don, Wednesday, November 12, 2008, 12:51:10 AM, you wrote: > Do you have an example of a mutable state/ IO bound application, like, > hmm, a window manager or a revision control system or a file system...? not I/O, but IO :) btw, i use C++ for speed-critical code (compression & encryprion) and Haskell/GHC for everything else in my FreeArc project (it has 19k downloads ATM). i also plan to switch to C# for GUI part since gtk2hs provides less features, less documented, les debugged, doesn't have IDE and my partner doesnt know Haskell :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From consalus at gmail.com Tue Nov 11 17:23:02 2008 From: consalus at gmail.com (Kyle Consalus) Date: Tue Nov 11 17:17:33 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <20081111215110.GQ28091@scytale.galois.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com> Message-ID: <9cc3782b0811111423m1a4247a1j4e4b8ef8fb2c6fb7@mail.gmail.com> On Tue, Nov 11, 2008 at 1:51 PM, Don Stewart wrote: > consalus: >> On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley wrote: >> > Hi everyone >> > >> > So I should clarify I'm not a troll and do "see the Haskell light". But >> > one thing I can never answer when preaching to others is "what does >> > Haskell not do well?" >> > >> > Usually I'll avoid then question and explain that it is a 'complete' >> > language and we do have more than enough libraries to make it useful and >> > productive. But I'd be keen to know if people have any anecdotes, >> > ideally ones which can subsequently be twisted into an argument for >> > Haskell ;) >> > >> > Cheers, >> > >> > Dave >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe@haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >> >> I think some would disagree with me, but I would advise against using >> haskell for a task that necessarily requires a lot of mutable state >> and IO and for which serious performance is a big factor. I'm not >> talking about stuff that can be approximated by zippers and whatnot, >> but rather situations where IORefs abound and data has identity. >> Haskell can quite capably do mutable state and IO, but if your task is >> all mutable state and IO, I'd lean toward a language that makes it >> easier (OCaml, perhaps). > > Do you have an example of a mutable state/ IO bound application, like, > hmm, a window manager or a revision control system or a file system...? > > -- Don > Of course, with a lot of skill, good design, and a pile of language extensions state/io-heavy Haskell code can be clean and flexible. Performance can be pretty good, and for complex algorithmic code arguably a better choice than most other languages. Still, neither of the projects you reference (to my knowledge) have a mutation-heavy inner computation loop. XMonad does all of its mutation in a custom monad that is ReaderT StateT IO or something similar, and it apparently works beautifully. However, my understanding is that stack of monad transformers tend not to be particularly efficient, and while that usually isn't an issue, the case that I'm talking about is that where mutation performance is a major concern. Other languages offer similar expressive power, minus the joys of laziness and referential transparency. Persistent data structures are great, but if you're not using the persistence it is less convenient and less efficient. So again, Haskell _can_ do mutation and IO just fine, but if laziness, purity, and immutability will be the rare exception rather than the rule, might be easier to use a language that makes strictness and impurity easier. (Unless you're a Haskell guru, in which case I imagine Haskell is always the most convenient language to use). From dons at galois.com Tue Nov 11 17:24:41 2008 From: dons at galois.com (Don Stewart) Date: Tue Nov 11 17:19:11 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <9cc3782b0811111423m1a4247a1j4e4b8ef8fb2c6fb7@mail.gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com> <9cc3782b0811111423m1a4247a1j4e4b8ef8fb2c6fb7@mail.gmail.com> Message-ID: <20081111222441.GU28091@scytale.galois.com> consalus: > On Tue, Nov 11, 2008 at 1:51 PM, Don Stewart wrote: > > consalus: > >> On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley wrote: > >> > Hi everyone > >> > > >> > So I should clarify I'm not a troll and do "see the Haskell light". But > >> > one thing I can never answer when preaching to others is "what does > >> > Haskell not do well?" > >> > > >> > Usually I'll avoid then question and explain that it is a 'complete' > >> > language and we do have more than enough libraries to make it useful and > >> > productive. But I'd be keen to know if people have any anecdotes, > >> > ideally ones which can subsequently be twisted into an argument for > >> > Haskell ;) > >> > > >> > Cheers, > >> > > >> > Dave > >> > > >> > _______________________________________________ > >> > Haskell-Cafe mailing list > >> > Haskell-Cafe@haskell.org > >> > http://www.haskell.org/mailman/listinfo/haskell-cafe > >> > > >> > >> I think some would disagree with me, but I would advise against using > >> haskell for a task that necessarily requires a lot of mutable state > >> and IO and for which serious performance is a big factor. I'm not > >> talking about stuff that can be approximated by zippers and whatnot, > >> but rather situations where IORefs abound and data has identity. > >> Haskell can quite capably do mutable state and IO, but if your task is > >> all mutable state and IO, I'd lean toward a language that makes it > >> easier (OCaml, perhaps). > > > > Do you have an example of a mutable state/ IO bound application, like, > > hmm, a window manager or a revision control system or a file system...? > > > > -- Don > > > > Of course, with a lot of skill, good design, and a pile of language > extensions state/io-heavy Haskell code can be clean and flexible. > Performance can be pretty good, and for complex algorithmic code > arguably a better choice than most other languages. Still, neither of > the projects you reference (to my knowledge) have a mutation-heavy > inner computation loop. Data.ByteString is full of mutation-heavy inner loops. There's nothing magic about it. -- Don From bulat.ziganshin at gmail.com Tue Nov 11 17:24:56 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 11 17:19:36 2008 Subject: [Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays In-Reply-To: <20081111222118.GT28091@scytale.galois.com> References: <182039970.20081111232507@gmail.com> <64F04C9398A52E43B208634452B7D00B0407B3AA@EMAIL01.pnl.gov> <14010527201.20081112000951@gmail.com> <20081111215133.GR28091@scytale.galois.com> <1047886631.20081112011432@gmail.com> <20081111222118.GT28091@scytale.galois.com> Message-ID: <1043994445.20081112012456@gmail.com> Hello Don, Wednesday, November 12, 2008, 1:21:18 AM, you wrote: > If this structure is useful, you should release it on Hackage. > You've not tested the performance though, I imagine, versus > say, hasing into an IntMap? you know that making all these things need a time. sorry, ATM i think that my compression projects makes more sense, so to the Haskell i'm just user -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From aeyakovenko at gmail.com Tue Nov 11 17:25:16 2008 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Tue Nov 11 17:19:48 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <20081111215110.GQ28091@scytale.galois.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com> Message-ID: Has there been any progress in getting ghc set up for porting to non x86/unix/windows platforms? Can it generate ropi code? It would also be nice to be able to compile to C that rvct/arm tools can compile in thumb mode. Its whats stopping me from trying to use it for mobile development. From igloo at earth.li Tue Nov 11 17:26:19 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Nov 11 17:20:51 2008 Subject: [Haskell-cafe] Trouble installing ghc-6.10.1 on linux In-Reply-To: <6205bd290811100505o4be9248pfe0b70a106692ec2@mail.gmail.com> References: <6205bd290811100505o4be9248pfe0b70a106692ec2@mail.gmail.com> Message-ID: <20081111222619.GA31442@matrix.chaos.earth.li> Hi Bit, On Mon, Nov 10, 2008 at 03:05:23PM +0200, Bit Connor wrote: > > First I tried the binary version ghc-6.10.1-i386-unknown-linux.tar.bz2 > and I very quickly get this error: > > $ ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > Which we'll further canonicalise into: i386-unknown-linux > checking for path to top of build tree... configure: error: cannot > determine current directory > $ This probably means your libc is too old for the bindist to work. Presumably running utils/pwd/pwd forwardslash gives a SIGFPE or similar? > Next I tried building the source version ghc-6.10.1-src.tar.bz2 using > ghc 6.6 that is already installed. configure works but make eventually > dies with: > > ... > Configuring ghc-6.10.1... > cabal-bin: At least the following dependencies are missing: > Cabal -any, This is the output of a cabal-bin command, right? Appending -v to the commandline might shed some light on what's going wrong. Or if that doesn't help, try "-v 3". Thanks Ian From jefferson.r.heard at gmail.com Tue Nov 11 17:26:35 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Tue Nov 11 17:21:07 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <9cc3782b0811111423m1a4247a1j4e4b8ef8fb2c6fb7@mail.gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com> <9cc3782b0811111423m1a4247a1j4e4b8ef8fb2c6fb7@mail.gmail.com> Message-ID: <4165d3a70811111426m3e0e4594m684950cc5cd7851@mail.gmail.com> Kyle, I would say that most apps don't actually require that you write a mutation heavy inner loop. They can be written either way, and Haskell gives you the facility to do both. Even my field, which is visualization can be written either way. I write with a mutation heavy inner loop myself, because it's how I started out, and I haven't had any trouble with performance. OpenGL is always my upper bound. Even 2D code, which I've written on occasion seems not to suffer. On Tue, Nov 11, 2008 at 5:23 PM, Kyle Consalus wrote: > On Tue, Nov 11, 2008 at 1:51 PM, Don Stewart wrote: >> consalus: >>> On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley wrote: >>> > Hi everyone >>> > >>> > So I should clarify I'm not a troll and do "see the Haskell light". But >>> > one thing I can never answer when preaching to others is "what does >>> > Haskell not do well?" >>> > >>> > Usually I'll avoid then question and explain that it is a 'complete' >>> > language and we do have more than enough libraries to make it useful and >>> > productive. But I'd be keen to know if people have any anecdotes, >>> > ideally ones which can subsequently be twisted into an argument for >>> > Haskell ;) >>> > >>> > Cheers, >>> > >>> > Dave >>> > >>> > _______________________________________________ >>> > Haskell-Cafe mailing list >>> > Haskell-Cafe@haskell.org >>> > http://www.haskell.org/mailman/listinfo/haskell-cafe >>> > >>> >>> I think some would disagree with me, but I would advise against using >>> haskell for a task that necessarily requires a lot of mutable state >>> and IO and for which serious performance is a big factor. I'm not >>> talking about stuff that can be approximated by zippers and whatnot, >>> but rather situations where IORefs abound and data has identity. >>> Haskell can quite capably do mutable state and IO, but if your task is >>> all mutable state and IO, I'd lean toward a language that makes it >>> easier (OCaml, perhaps). >> >> Do you have an example of a mutable state/ IO bound application, like, >> hmm, a window manager or a revision control system or a file system...? >> >> -- Don >> > > Of course, with a lot of skill, good design, and a pile of language > extensions state/io-heavy > Haskell code can be clean and flexible. Performance can be pretty > good, and for complex algorithmic > code arguably a better choice than most other languages. Still, > neither of the projects you reference (to my knowledge) > have a mutation-heavy inner computation loop. XMonad does all of its > mutation in a custom monad that is ReaderT StateT IO or something > similar, and it apparently works beautifully. However, my > understanding is that stack of monad transformers tend not to be > particularly efficient, and while that usually isn't an issue, the > case that I'm talking about is that where mutation > performance is a major concern. > Other languages offer similar expressive power, minus the joys of > laziness and referential transparency. > Persistent data structures are great, but if you're not using the > persistence it is less convenient and less efficient. > So again, Haskell _can_ do mutation and IO just fine, but if laziness, > purity, and immutability will be the rare exception > rather than the rule, might be easier to use a language that makes > strictness and impurity easier. > (Unless you're a Haskell guru, in which case I imagine Haskell is > always the most convenient language to use). > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From ales.bizjak0 at gmail.com Tue Nov 11 17:31:10 2008 From: ales.bizjak0 at gmail.com (=?utf-8?B?QWxlxaEgQml6amFr?=) Date: Tue Nov 11 17:25:43 2008 Subject: [Haskell-cafe] GHC 6.10, strange behaviour when profiling? In-Reply-To: <916b84820811110254q61b5211dl1d93fef26432c69a@mail.gmail.com> References: <916b84820811110254q61b5211dl1d93fef26432c69a@mail.gmail.com> Message-ID: On Tue, 11 Nov 2008 11:54:57 +0100, Thomas Schilling wrote: > I think you hit bug http://hackage.haskell.org/trac/ghc/ticket/2747, > which is an accounting bug in the garbage collector and goes away when > you trigger more garbage collections (which -hc does, I think). > Please file a bug report anyway, so we can verify that it is indeed > not a new bug. (Since the profiler modifies the program it can turn > on or off different optimisations, so it's quite possible that there > are other reasons for this behaviour.) I don't think compiling for profiling has anything to do with it because when compiling with just ghc --make -O2 Test.hs and then running with -hT behaves as it did with -hc and running without -hT eats up memory. I did some further tests and it seems that this is indeed the same bug as above. I will try the fix and if it doesn't fix things for me I will try to put together a minimal case where this happens and file a new bug report. Best regards, Ale? From jason.dusek at gmail.com Tue Nov 11 17:48:04 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Tue Nov 11 17:42:34 2008 Subject: [Haskell-cafe] Re: reliable (bi)directional pipe to a process In-Reply-To: References: <20081111070438.13467AE53@Adric.metnet.fnmoc.navy.mil> Message-ID: <42784f260811111448l5b069b3bm470f2187fb51ead9@mail.gmail.com> As an aside, my present problem really seems to be fixed -- I am able to move files of more than 2MB from one process to another within my Haskell program. In my program, I take the input file, turn it into a ByteString, pass it to process one, capture the result as a ByteString, pass it to process two, caputre that result as a ByteString and then put the ByteString into a file. Of course we'll see whether it really works in the next few days here -- but after I got the forking right I really there's little else to be done. However, it's clear this has been a problem in the past. Even if we just use this thread to collect "incidents" -- less specific than bugs, but more precise than simple suggestions of inadequacy -- it would help everyone to know what the limits are with the present runtime. -- _jsn From claus.reinke at talk21.com Tue Nov 11 18:42:57 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Nov 11 18:37:32 2008 Subject: Go Haskell! (was: [Haskell-cafe] What *not* to use Haskell for) References: <1226399902.6496.9.camel@rubix.office.last.fm><9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com> Message-ID: > Do you have an example of a mutable state/ IO bound application, like, > hmm, a window manager or a revision control system or a file system...? If you're looking for a challenge, how about this one (there used to be lots of Haskellers into this game, any of you still around?-): http://computer-go.org/pipermail/computer-go/2008-October/016680.html The specification is the numbered list at the end of the message, or in the zip file with the Java example implementation (README). Actually, the interesting part from a performance perspective doesn't even require GTP or AMAF, just implement the random legal playouts for a 9x9 board, do a loop over them, keeping some basic win/loose/game length statistics. Can you complete that in competitive speed, preferably from the specs, without just transliterating the low-level Java code? I won't tell you yet what typical playouts-per-second-per-core numbers are floating about for "lightly" optimised code; try to improve your code and say "stop, this is good enough" before comparing with the Java bot runtimes. You'll probably have no room left for any high-level operations, ending up with mostly imperatively threaded array manipulations in a loop that is expected to be run several thousand times per real-game move (the idea being to run lots of dumb, but legal, simulations to the end, where evaluation is easy, gather statistics, then choose the move that seems to have the most potential). Bonus points if you can preserve any of the high-level advantages of working in Haskell (such as easy debuggability, because there will be bugs, especially if you can't afford to maintain redundant information representations) without sacrificing speed. (*) As specified, the bot won't win any tournaments - it is the starting point (or remote ancestor) for the current champions, with lots of room for algorithmic improvement, not to mention actual game knowledge, tree search and parallelization (the configurations being used for tournaments and exhibition games are highly parallel). The reference spec is a recent effort, meant to provide a first milestone for aspiring Go programmers to compare their code against, while also inviting programmers to to show how their favourite language is eminently suitable for Go programming (without sacrificing performance!). There are versions in Java, D, C++, C#, and C around somewhere, possibly others. But: please, no language evangelism on that mailing list! Those people seem decent, peaceful and open-minded (there's even a Haskell spec of a simple rule set here http://homepages.cwi.nl/~tromp/go.html ). And some of them have years (a few even decades) of experience, much of which is made available in the mailinglist archives and bibliography (pointers available on request - if you wanted to get serious about playing with Go programming, you'd be expected to mine the archives and bibliography, because just about anything you'll come up with in your first few months will have been discussed already;-), in spite of commercial interests and ongoing competitions. They are already tired and wary of useless language wars (who isn't?). Claus (who has been wanting to write a Go player ever since he had to decide between research and learning more Go, either one trying to eat all available time and then some; perhaps I should write a researcher instead, and return to playing Go?-) (*) it would be nice if the sequential baseline performance of functional Haskell/Ghc arrays would be better, btw; that would make the ongoing work on parallel arrays much more interesting. From arnarbi at gmail.com Tue Nov 11 19:34:48 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Tue Nov 11 19:29:18 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <1226399902.6496.9.camel@rubix.office.last.fm> References: <1226399902.6496.9.camel@rubix.office.last.fm> Message-ID: <28012bc60811111634y746dd0d8hc12937026778c875@mail.gmail.com> Hi again, On Tue, Nov 11, 2008 at 11:38, Dave Tapley wrote: > So I should clarify I'm not a troll and do "see the Haskell light". But > one thing I can never answer when preaching to others is "what does > Haskell not do well?" C does extremely well when you want to write low level exploits, such as meddling with memory, the machine stack and others. This goes also for writing device drivers, media codecs, compression algorithms etc. and applications that are mostly about copying bits (with some transformations) between various memory locations. I imagine this kind of thing would be very hard to write in Haskell. Does that count? cheers, Arnar From niklas.broberg at gmail.com Tue Nov 11 19:59:01 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Tue Nov 11 19:53:31 2008 Subject: [Haskell-cafe] compiling haskell-src-exts in 6.10 In-Reply-To: <7b92c2840811110420i370e124dl616373df08373d7e@mail.gmail.com> References: <7b92c2840811110420i370e124dl616373df08373d7e@mail.gmail.com> Message-ID: 2008/11/11 Hugo Pacheco : > When installing package haskell-src-exts via cabal install, I get the error > Language/Haskell/Exts/Syntax.hs:102:7: > Could not find module `Data.Data': > it is a member of package base, which is hidden > > However, when manually installing > runhaskell Setup.hs configure/build/install > It works fine > Somehow package base is not available in cabal.. don't know why. Like Brandon said, this is the case of cabal-install trying to be "clever" and picking base-3 as the default even when base-4 is available, while I in turn was trying to be "clever" in picking the right version of base depending on which compiler was used. I'm not sure who of us was actually the least clever, but in hindsight I think neither was a very good choice. I promised a new release when 6.10.1 proper was out, so here we go: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.10 Only change is that it will no longer work without the split base, explicitly expecting base >= 4. Cheers, /Niklas From blancolioni at gmail.com Tue Nov 11 20:28:17 2008 From: blancolioni at gmail.com (Fraser Wilson) Date: Tue Nov 11 20:23:05 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? In-Reply-To: References: <457DB857-8E23-4DF3-964E-D54183B732EA@pikewerks.com> Message-ID: I had a proof of concept lying around a couple of years ago in which a big complicated Ada program called a big complicated Haskell program and vice versa. The tricky bit from memory was making it link, and satisfying their rumtime initialisation requirements. No explicit C was required I think. Fraser On 11 nov 2008, at 18:09, Colin Paul Adams wrote: >>>>>> "Jake" == Jake Mcarthur writes: > > Jake> Actually, that's not the whole story. I didn't realize until > Jake> I sent it. There does exist good documentation for this, I > Jake> promise. > > Good. Let me know where it is when you track it down. > > The link you pointed me too doesn't seem to address my question > directly. Also, it only talks about C. > > If I want to call Haskell (and I do, perhaps) from another > garbage-collected language (Eiffel, in particular) using C as the > mutually understood language, am I not going to run into big problems? > -- > Colin Adams > Preston Lancashire > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From wren at freegeek.org Tue Nov 11 21:02:59 2008 From: wren at freegeek.org (wren ng thornton) Date: Tue Nov 11 20:57:28 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <1226399902.6496.9.camel@rubix.office.last.fm> References: <1226399902.6496.9.camel@rubix.office.last.fm> Message-ID: <491A3953.7090305@freegeek.org> Dave Tapley wrote: > Hi everyone > > So I should clarify I'm not a troll and do "see the Haskell light". But > one thing I can never answer when preaching to others is "what does > Haskell not do well?" > > Usually I'll avoid then question and explain that it is a 'complete' > language and we do have more than enough libraries to make it useful and > productive. But I'd be keen to know if people have any anecdotes, > ideally ones which can subsequently be twisted into an argument for > Haskell ;) With the appropriate caveats about particular subdomains (see final paragraph), I wouldn't use Haskell for scripting. That is, (1) for Bash-style programming where 95% of the code is just invoking *nix jobs, or (2) for very simple yet regex-heavy scripts where Perl/Awk/Sed is often used. Re #1: Honestly, I don't see anything other than a dedicated competitor being able to unseat Bourne/Bash at this task. Certainly a competitor would have much room for improvement-- what with being able to replace string-rewriting semantics with term-rewriting semantics, vastly improving type safety and catching innumerable bugs. However, with unsavory frequency, it is exactly those type-unsafe substitutions which can make shell scripting cleaner and more direct than a type-safe alternative. Having type safety as well as this sort of non-compositional structure would take a good deal of work to get right. Re #2: People often complain about spooky Perl that uses things like implicit $_ or other hidden variables. While these constructs can make any sizable project unmaintainable, for the quick and dirty jobs they're just what's needed to get things done with clarity. While ByteString code using regexes is just as fast in Haskell, it's often more than twice as long as the Perl, Sed, or Awk equivalents because many of the basic control structures (like Perl's -n, -p, -l,... flags) aren't already provided. That said, this isn't necessarily a bad thing for Haskell. "Real" programming languages often don't do so well in these areas (Perl being the exception), and they don't feel too bad about it. Both varieties of shell scripting are very much of the DSL nature; for programs with a significant amount of "actual logic" instead of mere plumbing or regexing, Haskell can certainly outshine these competitors. On the one hand, C and friends fight dirty and much work has been done so Haskell can join in on the bit-bashing glory. However, shell scripting is a whole different kind of imperative muck and very little work (that I've seen) has tried to get Haskell to jump down in the sewers with them. -- Live well, ~wren From skynare at gmail.com Tue Nov 11 22:41:48 2008 From: skynare at gmail.com (sam lee) Date: Tue Nov 11 22:36:18 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <491A3953.7090305@freegeek.org> References: <1226399902.6496.9.camel@rubix.office.last.fm> <491A3953.7090305@freegeek.org> Message-ID: <4e7aa0f80811111941k32f80909ld7cec678d6a1b8a8@mail.gmail.com> I haven't found multitrack audio recording applications written in Haskell. These are usually written in C++ using Jack audio or ASIO. This probably means that it is not a good idea to write real time audio applications in Haskell at the moment. So, probably avoid writing applications that use a high frequency timer and IO that should be synchronous to the timer in Haskell. On Tue, Nov 11, 2008 at 9:02 PM, wren ng thornton wrote: > Dave Tapley wrote: >> >> Hi everyone >> >> So I should clarify I'm not a troll and do "see the Haskell light". But >> one thing I can never answer when preaching to others is "what does >> Haskell not do well?" >> >> Usually I'll avoid then question and explain that it is a 'complete' >> language and we do have more than enough libraries to make it useful and >> productive. But I'd be keen to know if people have any anecdotes, >> ideally ones which can subsequently be twisted into an argument for >> Haskell ;) > > With the appropriate caveats about particular subdomains (see final > paragraph), I wouldn't use Haskell for scripting. That is, (1) for > Bash-style programming where 95% of the code is just invoking *nix jobs, or > (2) for very simple yet regex-heavy scripts where Perl/Awk/Sed is often > used. > > Re #1: Honestly, I don't see anything other than a dedicated competitor > being able to unseat Bourne/Bash at this task. Certainly a competitor would > have much room for improvement-- what with being able to replace > string-rewriting semantics with term-rewriting semantics, vastly improving > type safety and catching innumerable bugs. However, with unsavory frequency, > it is exactly those type-unsafe substitutions which can make shell scripting > cleaner and more direct than a type-safe alternative. Having type safety as > well as this sort of non-compositional structure would take a good deal of > work to get right. > > Re #2: People often complain about spooky Perl that uses things like > implicit $_ or other hidden variables. While these constructs can make any > sizable project unmaintainable, for the quick and dirty jobs they're just > what's needed to get things done with clarity. While ByteString code using > regexes is just as fast in Haskell, it's often more than twice as long as > the Perl, Sed, or Awk equivalents because many of the basic control > structures (like Perl's -n, -p, -l,... flags) aren't already provided. > > > That said, this isn't necessarily a bad thing for Haskell. "Real" > programming languages often don't do so well in these areas (Perl being the > exception), and they don't feel too bad about it. Both varieties of shell > scripting are very much of the DSL nature; for programs with a significant > amount of "actual logic" instead of mere plumbing or regexing, Haskell can > certainly outshine these competitors. On the one hand, C and friends fight > dirty and much work has been done so Haskell can join in on the bit-bashing > glory. However, shell scripting is a whole different kind of imperative muck > and very little work (that I've seen) has tried to get Haskell to jump down > in the sewers with them. > > -- > Live well, > ~wren > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jeremy at n-heptane.com Wed Nov 12 01:07:28 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Wed Nov 12 00:52:59 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <4e7aa0f80811111941k32f80909ld7cec678d6a1b8a8@mail.gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <491A3953.7090305@freegeek.org> <4e7aa0f80811111941k32f80909ld7cec678d6a1b8a8@mail.gmail.com> Message-ID: <873ahxwk7z.wl%jeremy@n-heptane.com> At Tue, 11 Nov 2008 22:41:48 -0500, sam lee wrote: > > I haven't found multitrack audio recording applications written in > Haskell. These are usually written in C++ using Jack audio or ASIO. > This probably means that it is not a good idea to write real time > audio applications in Haskell at the moment. There are at least two Haskell bindings to JACK. I wrote one of them. The big issue is (no surprise) garbage collection. Audio stuff can generate a lot of garbage fast if you aren't careful. And the stop-the-world collection can happen at unfortunate times. The uvector library might help things -- but ultimately Haskell would need a more realtime friendly garbage collector. So, realtime audio can be done in Haskell today, but is is definitely fragile at best. - jeremy From eelco at lempsink.nl Wed Nov 12 01:55:51 2008 From: eelco at lempsink.nl (Eelco Lempsink) Date: Wed Nov 12 01:50:24 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <1226399902.6496.9.camel@rubix.office.last.fm> References: <1226399902.6496.9.camel@rubix.office.last.fm> Message-ID: <237A86CA-4580-4FDF-9D21-EAC0EB2ECB8C@lempsink.nl> On 11 nov 2008, at 11:38, Dave Tapley wrote: > Usually I'll avoid then question and explain that it is a 'complete' > language and we do have more than enough libraries to make it useful > and > productive. But I'd be keen to know if people have any anecdotes, > ideally ones which can subsequently be twisted into an argument for > Haskell ;) Working with relational databases can be a bit cumbersome. There's some bitrot in the HaskellDB packages in general, so taking a more low- level approach seems sensible, but because the lack of extensible records you don't get much help from the compiler, so you need to do most of the checking (and 'marshalling') yourself. In that sense, it's not worse than doing it with most other languages, except that for those languages there are often high-level libraries available to do, for example, cute things like object relational mapping (ORM). -- Regards, Eelco Lempsink -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081112/82fecd76/PGP.bin From ketil at malde.org Wed Nov 12 03:19:25 2008 From: ketil at malde.org (Ketil Malde) Date: Wed Nov 12 03:13:55 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <20081111222441.GU28091@scytale.galois.com> (Don Stewart's message of "Tue\, 11 Nov 2008 14\:24\:41 -0800") References: <1226399902.6496.9.camel@rubix.office.last.fm> <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com> <9cc3782b0811111423m1a4247a1j4e4b8ef8fb2c6fb7@mail.gmail.com> <20081111222441.GU28091@scytale.galois.com> Message-ID: <8763mt4ar6.fsf@malde.org> Don Stewart writes: > Data.ByteString is full of mutation-heavy inner loops. I suspect you are missing Kyle's point, which I interpret to be more like what Paul Graham talks about in "ANSI Common Lisp": [OO] provides a structured way to write spaghetti code. [...] For programs that would have ended up as spaghetti anyway, the object oriented model is good: they will at least be structured spaghetti. In my opinion, Haskell is pretty bad at spaghetti. And although it is possible that some programs simply need to be spaghetti-structured, I still think not supporting it is a good thing - Haskell should instead provide the tools for writing an equivalent non-spaghettized program. Bytestrings have mutation-heavy inner loops, but localized, well-structured, and exporting a neat, pure interface, so they don't count here. > There's nothing magic about it. Now you're just being modest. -k -- If I haven't seen further, it is by standing in the footprints of giants From waldmann at imn.htwk-leipzig.de Wed Nov 12 03:31:32 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Wed Nov 12 03:26:29 2008 Subject: [Haskell-cafe] Re: reliable (bi)directional pipe to a process References: <20081111070438.13467AE53@Adric.metnet.fnmoc.navy.mil> Message-ID: > http://okmij.org/ftp/Haskell/MySysOpen.hs when I run the test case in the file, the first read_back gets until count=9890, then hangs (I don't see "Doing it again") (CPU is idle) (with ghc-6.10.1) From ketil at malde.org Wed Nov 12 03:45:50 2008 From: ketil at malde.org (Ketil Malde) Date: Wed Nov 12 03:40:19 2008 Subject: [Haskell-cafe] ByteString/parsec In-Reply-To: (Pieter Laeremans's message of "Tue\, 11 Nov 2008 16\:38\:06 +0100") References: Message-ID: <87vdut2uyp.fsf@malde.org> "Pieter Laeremans" writes: > Are there any good examples of open source projects which parse > ByteString data ? Don't know about "good", but here are some working examples that may or may not be useful to you. Pointers are inside the darcs repo, you can of course 'darcs get http://malde.org/~ketil/biohaskell/biolib' to obtain the whole deal. A simple parser for the even simpler FASTA format: http://malde.org/~ketil/biohaskell/biolib/Bio/Sequence/Fasta.hs Parser to decode the ACE format by tokenizing to Bytestring, then using Parsec: http://malde.org/~ketil/biohaskell/biolib/Bio/Alignment/ACE.hs The repo also contains parsers for other formats like FASTQ, and binary formats like SFF. Please email me with any questions or comments. -k -- If I haven't seen further, it is by standing in the footprints of giants From pkeir at dcs.gla.ac.uk Wed Nov 12 05:09:14 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Wed Nov 12 05:03:43 2008 Subject: [Haskell-cafe] Searching for ADT patterns with elem and find Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80CCADB@EX2.ad.dcs.gla.ac.uk> Hi All, If I have an ADT, say data T = A String Integer | B Double | C deriving(Eq) and I want to find if a list (ts) of type T contains an element of subtype "B Double", must my "containsTypeX" function use a second "isTypeX" function as follows: isTypeB :: T -> Bool isTypeB (B _) = True isTypeB _ = False containsTypeB :: [T] -> Bool containsTypeB ts = maybe False (\x -> True) (find isTypeB ts) I understand that while something like "find C ts" will work, "find (isTypeB _) ts" will not, but is there no such thing as a pattern combinator(?), or lambda that could help with this situation. I find I have many individual "isTypeB" functions now. Regards, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081112/495bfdba/attachment.htm From andy at nobugs.org Wed Nov 12 05:11:53 2008 From: andy at nobugs.org (Andrew Birkett) Date: Wed Nov 12 05:06:23 2008 Subject: [Haskell-cafe] Proof that Haskell is RT Message-ID: <491AABE9.5070700@nobugs.org> Hi, Is a formal proof that the Haskell language is referentially transparent? Many people state "haskell is RT" without backing up that claim. I know that, in practice, I can't write any counter-examples but that's a bit handy-wavy. Is there a formal proof that, for all possible haskell programs, we can replace coreferent expressions without changing the meaning of a program? (I was writing a blog post about the origins of the phrase 'referentially transparent' and it made me think about this) Andrew -- - http://www.nobugs.org - From tom.davie at gmail.com Wed Nov 12 05:19:15 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Wed Nov 12 05:13:45 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: <491AABE9.5070700@nobugs.org> References: <491AABE9.5070700@nobugs.org> Message-ID: <83B9C4BC-5F94-4D04-9737-063CB2F03921@gmail.com> On 12 Nov 2008, at 11:11, Andrew Birkett wrote: > Hi, > > Is a formal proof that the Haskell language is referentially > transparent? Many people state "haskell is RT" without backing up > that claim. I know that, in practice, I can't write any counter- > examples but that's a bit handy-wavy. Is there a formal proof that, > for all possible haskell programs, we can replace coreferent > expressions without changing the meaning of a program? > > (I was writing a blog post about the origins of the phrase > 'referentially transparent' and it made me think about this) I think the informal proof goes along the lines of "because that's what the spec says" -- Haskell's operational semantics are not specified in the report, only IIRC a wooly description of having some sort of non-strict beta-reduction behavior. Bob From devriese at cs.tcd.ie Wed Nov 12 05:20:02 2008 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Wed Nov 12 05:14:43 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: <491AABE9.5070700@nobugs.org> References: <491AABE9.5070700@nobugs.org> Message-ID: <0566DF39-0F9D-44C8-85D2-972F8B364BCD@cs.tcd.ie> See "What is a purely functional language" by Sabry. Not quite a formal proof about *Haskell*, but then we would first need a formal semantics of Haskell to be able to do that proof ;-) On 12 Nov 2008, at 10:11, Andrew Birkett wrote: > Hi, > > Is a formal proof that the Haskell language is referentially > transparent? Many people state "haskell is RT" without backing up > that claim. I know that, in practice, I can't write any counter- > examples but that's a bit handy-wavy. Is there a formal proof that, > for all possible haskell programs, we can replace coreferent > expressions without changing the meaning of a program? > > (I was writing a blog post about the origins of the phrase > 'referentially transparent' and it made me think about this) > > Andrew > > -- > - http://www.nobugs.org - > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From voigt at tcs.inf.tu-dresden.de Wed Nov 12 05:21:32 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Wed Nov 12 05:16:04 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: <491AABE9.5070700@nobugs.org> References: <491AABE9.5070700@nobugs.org> Message-ID: <491AAE2C.6020001@tcs.inf.tu-dresden.de> Andrew Birkett wrote: > Hi, > > Is a formal proof that the Haskell language is referentially > transparent? Many people state "haskell is RT" without backing up that > claim. I know that, in practice, I can't write any counter-examples but > that's a bit handy-wavy. Is there a formal proof that, for all possible > haskell programs, we can replace coreferent expressions without changing > the meaning of a program? > > (I was writing a blog post about the origins of the phrase > 'referentially transparent' and it made me think about this) Answering this question, or actually even formalizing the statement you want to prove, is more or less equivalent to writing down a full denotational candidate semantics for Haskell in a compositional style, and proving that it is equivalent to the *actual* semantics of Haskell Nobody has done this. Well, there is no *actual* semantics anywhere around to which you one could prove equivalence. So, to be precise, the question you are interested in cannot even really be asked at the moment. Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From jules at jellybean.co.uk Wed Nov 12 05:21:45 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Nov 12 05:16:16 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: <491AABE9.5070700@nobugs.org> References: <491AABE9.5070700@nobugs.org> Message-ID: <491AAE39.9090005@jellybean.co.uk> Andrew Birkett wrote: > Hi, > > Is a formal proof that the Haskell language is referentially > transparent? Many people state "haskell is RT" without backing up that > claim. I know that, in practice, I can't write any counter-examples but > that's a bit handy-wavy. Is there a formal proof that, for all possible > haskell programs, we can replace coreferent expressions without changing > the meaning of a program? The (well, a natural approach to a) formal proof would be to give a formal semantics for haskell. Referential transparency would be an obvious property of the semantics. Soundness would show that it carried over to the language. Jules From neil.mitchell.2 at credit-suisse.com Wed Nov 12 05:23:35 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Wed Nov 12 05:19:13 2008 Subject: [Haskell-cafe] Searching for ADT patterns with elem and find In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CCADB@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CCADB@EX2.ad.dcs.gla.ac.uk> Message-ID: Hi Paul, maybe False (\x -> True) (find isTypeB ts) This can be more neatly expressed as: isJust (find isTypeB ts) But your entire thing can be expressed as: containsTypeB ts = any isTypeB ts I recommend reading through the Prelude interface and the List interface, it has many useful functions that will help. Thanks Neil ________________________________ From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Paul Keir Sent: 12 November 2008 10:09 am To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Searching for ADT patterns with elem and find Hi All, If I have an ADT, say data T = A String Integer | B Double | C deriving(Eq) and I want to find if a list (ts) of type T contains an element of subtype "B Double", must my "containsTypeX" function use a second "isTypeX" function as follows: isTypeB :: T -> Bool isTypeB (B _) = True isTypeB _ = False containsTypeB :: [T] -> Bool containsTypeB ts = maybe False (\x -> True) (find isTypeB ts) I understand that while something like "find C ts" will work, "find (isTypeB _) ts" will not, but is there no such thing as a pattern combinator(?), or lambda that could help with this situation. I find I have many individual "isTypeB" functions now. Regards, Paul ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081112/49089cfb/attachment.htm From dukedave at gmail.com Wed Nov 12 05:30:08 2008 From: dukedave at gmail.com (Dave Tapley) Date: Wed Nov 12 05:24:41 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? In-Reply-To: References: Message-ID: <1226485808.6661.4.camel@rubix.office.last.fm> Hi Colin As an alternative you may consider using Thrift: http://incubator.apache.org/thrift/ Cheers, Dave On Tue, 2008-11-11 at 16:45 +0000, Colin Paul Adams wrote: > Is there a way to call Haskell code from other languages? I have looked on > the wiki, and as far as I can see, it only talks about the other way > round (when Haskell is the main program). From agocorona at gmail.com Wed Nov 12 05:38:03 2008 From: agocorona at gmail.com (Alberto G. Corona ) Date: Wed Nov 12 05:32:31 2008 Subject: [Haskell-cafe] abstract extensible types? Message-ID: Is there any abstract container that permits the addition of new types of data? I know how to simulate the extension of Algebraic datatypes, but this does not permit the addition of data with new types in the same container and recover them in a type-safe way. Did I reinvent the Weel? I found something, that permits this for any Typeable datatype. For example x=5 list= [put x, put "hello"] [t1,t2 ]= list x' = get t1 :: Int s = get t2 :: String print (x' +1) -- 2 print s -- "hello" x''= get t2 :: Int --"get: casting from String to type Int" The code: data Abstract= forall a. Typeable a => T !String a class FromToAbstract x where put :: x -> Abstract get :: Abstract -> x unsafeGet :: Abstract -> x -- get(put x)== x instance Typeable x => FromToAbstract x where put x= T (typeString x) x get (Abstract type1 a)= if type2 == type1 then v else error ("get: casting "++ "from type "++type1++" to type "++type2) where v= unsafeCoerce a :: x type2= typeString v unsafeGet (Abstract type1 a)= unsafeCoerce a typeString !x= tyConString $ typeRepTyCon $ typeOf x instance Typeable T where typeOf _= mkTyConApp (mkTyCon "Abstract") [] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081112/127293e0/attachment.htm From Malcolm.Wallace at cs.york.ac.uk Wed Nov 12 05:55:58 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Nov 12 05:53:38 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: References: <1226399902.6496.9.camel@rubix.office.last.fm> <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com> Message-ID: <20081112105558.0cf7083e.Malcolm.Wallace@cs.york.ac.uk> "Anatoly Yakovenko" wrote: > Has there been any progress in getting ghc set up for porting to non > x86/unix/windows platforms? Can it generate ropi code? It would also > be nice to be able to compile to C that rvct/arm tools can compile in > thumb mode. AFAIK, you can bootstrap ghc onto lots of non-PC-centric platforms, using the unregisterized porting guide. However, it is not a trivial exercise, and it does not address the question of setting ghc up as a cross-compiler, should your device be too small to host ghc at all. Other Haskell compilers might be a better starting point. For instance, nhc98 uses portable C as a target language, and has a configure-time option to set it up as a cross-compiler. See http://www.cs.york.ac.uk/fp/nhc98/install.html (cross-compiler info towards the bottom of the page). The example given is for ARM/linux. Regards, Malcolm From marlowsd at gmail.com Wed Nov 12 07:18:01 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 12 07:12:36 2008 Subject: [Haskell-cafe] Re: reliable (bi)directional pipe to a process In-Reply-To: <20081111070438.13467AE53@Adric.metnet.fnmoc.navy.mil> References: <20081111070438.13467AE53@Adric.metnet.fnmoc.navy.mil> Message-ID: <491AC979.8000609@gmail.com> oleg@okmij.org wrote: > I'd like to point out a reliable, proven and simple way of interacting > with another process, via unidirectional or bidirectional pipes. The > method supports Unix sockets, pipes, and TCP sockets. > > I too have noticed insidious bugs in GHC run-time when communicating > with another process via a pipe. I tried to use runInteractiveProcess; > it worked -- up to file sizes of about 300Kb. Then GHC run-time seems > to `loses synchronization' -- and corrupts IO buffers, receiving stuff > that cannot have been possibly sent. This is because handle operations > are asynchronous and the GHC scheduler seems to have race conditions. > That behavior was totally unacceptable. I was writing a production > code, and can't afford such errors. If there are bugs of this kind, we really need to get them fixed - I'm not aware of anything like this being reported. Please, if anyone can reproduce this, or even if you can't, submit a bug giving as many details as you can. Cheers, Simon From lrpalmer at gmail.com Wed Nov 12 07:39:10 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Wed Nov 12 07:33:39 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: <491AAE39.9090005@jellybean.co.uk> References: <491AABE9.5070700@nobugs.org> <491AAE39.9090005@jellybean.co.uk> Message-ID: <7ca3f0160811120439j58ca666bxc950456330493022@mail.gmail.com> On Wed, Nov 12, 2008 at 3:21 AM, Jules Bean wrote: > Andrew Birkett wrote: >> >> Hi, >> >> Is a formal proof that the Haskell language is referentially transparent? >> Many people state "haskell is RT" without backing up that claim. I know >> that, in practice, I can't write any counter-examples but that's a bit >> handy-wavy. Is there a formal proof that, for all possible haskell >> programs, we can replace coreferent expressions without changing the meaning >> of a program? > > The (well, a natural approach to a) formal proof would be to give a formal > semantics for haskell. Haskell 98 does not seem that big to me (it's not teeny, but it's nothing like C++), yet we are continually embarrassed about not having any formal semantics. What are the challenges preventing its creation? Luke From tanielsen at gmail.com Wed Nov 12 07:39:50 2008 From: tanielsen at gmail.com (Tom Nielsen) Date: Wed Nov 12 07:34:19 2008 Subject: [Haskell-cafe] Searching for ADT patterns with elem and find In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CCADB@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CCADB@EX2.ad.dcs.gla.ac.uk> Message-ID: <78dc001e0811120439o51baf362m25c50f85f3d7f364@mail.gmail.com> somebody pointed out a few months back that list comprehensions do this nicely: containsTypeB ts = not $ null [x | (B x) <- ts] no need for defining isTypeB. not quite sure how you would write findBs :: [T]->[T] succinctly; maybe findBs ts = [b | b@(B _) <- ts] or findBs ts = [B x | (B x) <- ts] both of them compile but the first is ugly and the second is inefficient (Tags a new T for every hit). Tom 2008/11/12 Paul Keir : > Hi All, > > If I have an ADT, say > > data T > = A String Integer > | B Double > | C > deriving(Eq) > > and I want to find if a list (ts) of type T contains an element of subtype > "B Double", must my "containsTypeX" function use a second "isTypeX" function > as follows: > > isTypeB :: T -> Bool > isTypeB (B _) = True > isTypeB _ = False > > containsTypeB :: [T] -> Bool > containsTypeB ts = maybe False (\x -> True) (find isTypeB ts) > > I understand that while something like "find C ts" will work, "find (isTypeB > _) ts" will not, but is there no such thing as a pattern combinator(?), or > lambda that could help with this situation. I find I have many individual > "isTypeB" functions now. > > Regards, > Paul > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From thomas at cs.ru.nl Wed Nov 12 07:46:14 2008 From: thomas at cs.ru.nl (Thomas van Noort) Date: Wed Nov 12 07:40:42 2008 Subject: [Haskell-cafe] Proposal for associated type synonyms in Template Haskell In-Reply-To: <52f14b210811110311v8ab419au5f33b08b9681f84d@mail.gmail.com> References: <49104B62.5010308@cs.ru.nl> <491052AB.2010302@cs.ru.nl> <4b39c80a0811040600y16257eafh5037a851284af10e@mail.gmail.com> <4911B442.7080104@cs.ru.nl> <52f14b210811110311v8ab419au5f33b08b9681f84d@mail.gmail.com> Message-ID: <491AD016.7070900@cs.ru.nl> Hi Pedro, You are right, it is a partial implementation. We chose not to propose an implementation for associated datatypes and type families because it is unknown if there is a demand for it. But I don't think coming up with the TH AST modifications for associated type synonyms and type families is that much harder. Especially associated datatypes are very similar to associated type synonyms. The difficult part is in the GHC translation of course. Regards, Thomas Jos? Pedro Magalh?es wrote: > Hello Thomas, > > I see this is a proposal for a partial implementation of #1673 > (http://hackage.haskell.org/trac/ghc/ticket/1673). Maybe it would be > good if the remaining syntax (associated datatypes and type families) > would also be defined and implemented in TH. Or maybe there isn't much > demand for this?... > > > Cheers, > Pedro > > On Wed, Nov 5, 2008 at 15:57, Thomas van Noort > wrote: > > Hello, > > Recently, we released a library on Hackage for generic rewriting > (package "rewriting" if you are curious). The user of the library is > expected to define type class instances to enable rewriting on his > or her own datatypes. As these instances follow the datatype > declarations closely, we tried to generate the instances using > Template Haskell. Unfortunately, associated type synonyms are not > yet supported by TH. > > After a presentation at the WGP'08, Simon encouraged us to write a > proposal about adding associated type synonyms to TH, so that it can > be added to GHC. So, here is our proposal. > > The TH AST must allow 1) kind declarations of associated type synonyms > in class declarations and 2) their definitions in instance > declarations. For example, > > class Foo a where > type Bar a :: * > > instance Foo Int where > type Bar Int = String > > The TH library defines a datatype Dec which contains a constructor > for class declarations and instance declarations: > > data Dec > = ... > | ClassD Cxt Name [Name] [FunDep] [Dec] > | InstanceD Cxt Type [Dec] > ... > > 1) Associated type synonym kind declarations > > We suggest to add a constructor to the Dec type: > > ... > | AssocTySynKindD Name [Name] (Maybe Kind) > ... > > assocTySynKindD :: Name -> [Name] -> Maybe KindQ -> DecQ > > The first field is the name of the associated type synonym, the > second field is a list of type variables, and the third field is an > optional kind. Since kinds are not yet defined in TH, we have to add > some kind of kind definition (pun intended): > > data Kind > = StarK > | ArrowK Kind Kind > > type KindQ = Q Kind > starK :: KindQ > arrowK :: KindQ -> KindQ -> KindQ > > We explicitly choose not to reuse the Type type to define kinds > (i.e., type Kind = Type as in GHC) since we think a separation > between the two worlds is much clearer to the users of TH. > > 2) Associated type synonym definitions > > We suggest to add another constructor to the Dec type: > > ... > | AssocTySynD Name [Type] Type > ... > > assocTySynD :: Name -> [TypeQ] -> TypeQ -> DecQ > > The first field is the name of the type synonym, the second field is > a list of type arguments, and the third field is the body of the > type synonym. > > We would like to hear your comments to this proposal. > > Regards, > Thomas > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From lennart at augustsson.net Wed Nov 12 08:09:33 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Nov 12 08:04:00 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: <7ca3f0160811120439j58ca666bxc950456330493022@mail.gmail.com> References: <491AABE9.5070700@nobugs.org> <491AAE39.9090005@jellybean.co.uk> <7ca3f0160811120439j58ca666bxc950456330493022@mail.gmail.com> Message-ID: You can't write a straightforward dynamic semantics (in, say, denotational style) for Haskell. The problem is that with type classes you need to know the types compute the values. You could use a two step approach: first make a static semantics that does type inference/checking and translates Haskell into a different form that has resolved all overloading. And, secondly, you can write a dynamic semantics for that language. But since the semantics has to have the type inference engine inside it, it's going to be a pain. It's possible that there's some more direct approach that represents types as some kind of runtime values, but nobody (to my knowledge) has done that. -- Lennart On Wed, Nov 12, 2008 at 12:39 PM, Luke Palmer wrote: > On Wed, Nov 12, 2008 at 3:21 AM, Jules Bean wrote: >> Andrew Birkett wrote: >>> >>> Hi, >>> >>> Is a formal proof that the Haskell language is referentially transparent? >>> Many people state "haskell is RT" without backing up that claim. I know >>> that, in practice, I can't write any counter-examples but that's a bit >>> handy-wavy. Is there a formal proof that, for all possible haskell >>> programs, we can replace coreferent expressions without changing the meaning >>> of a program? >> >> The (well, a natural approach to a) formal proof would be to give a formal >> semantics for haskell. > > Haskell 98 does not seem that big to me (it's not teeny, but it's > nothing like C++), yet we are continually embarrassed about not having > any formal semantics. What are the challenges preventing its > creation? > > Luke > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From tux_rocker at reinier.de Wed Nov 12 08:22:22 2008 From: tux_rocker at reinier.de (Reinier Lamers) Date: Wed Nov 12 08:16:51 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <1226399902.6496.9.camel@rubix.office.last.fm> References: <1226399902.6496.9.camel@rubix.office.last.fm> Message-ID: 2008/11/11 Dave Tapley : > So I should clarify I'm not a troll and do "see the Haskell light". But > one thing I can never answer when preaching to others is "what does > Haskell not do well?" Let's say something controversial: I think that Haskell's type system gets in your way when you're writing one-shot scripts that don't need to conform to the highest correctness standards. Imagine typing a command at the shell prompt and getting the sort of abstract error message that Haskell compilers give every now and then, like: > whyerror.lhs:36:25: > Ambiguous type variable `a' in the constraint: > `Arrow a' arising from use of `>>>' at whyerror.lhs:36:25-27 > Possible cause: the monomorphism restriction applied to the > following: > liftA2' :: forall b a1 b1 c. (a1 -> b1 -> c) -> a b a1 -> a b > b1 -> a b c > (bound at whyerror.lhs:36:1) > unsplit' :: forall a1 b c. (a1 -> b -> c) -> a (a1, b) c > (bound at whyerror.lhs:34:1) > split' :: forall b. a b (b, b) (bound at whyerror.lhs:33:1) > Probable fix: give these definition(s) an explicit type signature > or use -fno-monomorphism-restriction You don't want to be bothered by such monstrosities (yes, they are, even though many of you may not see it because of years of conditioning) when you're just hacking up a simple script to make a catalog of your MP3 collection / check for patterns in log files / whatever. Also, in my experience Haskell is not so good at data structures where you can't do structural recursion easily, like graphs. In such cases you want a language with easy pointers and destructive updates. You can do those things in pure Haskell by using the ST monad, but the code will be more verbose than in Java or C++, and it will occasionally drive you insane with type messages like the above (You thought you could use '$' freely instead of application? Wrong!). Regards, Reinier From pkeir at dcs.gla.ac.uk Wed Nov 12 08:33:10 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Wed Nov 12 08:28:23 2008 Subject: [Haskell-cafe] Searching for ADT patterns with elem and find References: <3CDFB8AFEA98E34CB599475AB11589C80CCADB@EX2.ad.dcs.gla.ac.uk> Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80CCAE3@EX2.ad.dcs.gla.ac.uk> Thanks Neil, Great. I hadn't noticed "isJust", and I'd forgotten "any". Actually I was browsing Prelude just the other day and picked up "zipWith f as bs" as a replacement for "map f $ zip as bs". Cheers, Paul -----Original Message----- From: Mitchell, Neil [mailto:neil.mitchell.2@credit-suisse.com] Sent: Wed 12/11/2008 10:23 To: Paul Keir; haskell-cafe@haskell.org Subject: RE: [Haskell-cafe] Searching for ADT patterns with elem and find Hi Paul, maybe False (\x -> True) (find isTypeB ts) This can be more neatly expressed as: isJust (find isTypeB ts) But your entire thing can be expressed as: containsTypeB ts = any isTypeB ts I recommend reading through the Prelude interface and the List interface, it has many useful functions that will help. Thanks Neil ________________________________ From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Paul Keir Sent: 12 November 2008 10:09 am To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Searching for ADT patterns with elem and find Hi All, If I have an ADT, say data T = A String Integer | B Double | C deriving(Eq) and I want to find if a list (ts) of type T contains an element of subtype "B Double", must my "containsTypeX" function use a second "isTypeX" function as follows: isTypeB :: T -> Bool isTypeB (B _) = True isTypeB _ = False containsTypeB :: [T] -> Bool containsTypeB ts = maybe False (\x -> True) (find isTypeB ts) I understand that while something like "find C ts" will work, "find (isTypeB _) ts" will not, but is there no such thing as a pattern combinator(?), or lambda that could help with this situation. I find I have many individual "isTypeB" functions now. Regards, Paul ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081112/d1e330ff/attachment.htm From pkeir at dcs.gla.ac.uk Wed Nov 12 08:44:42 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Wed Nov 12 08:39:09 2008 Subject: [Haskell-cafe] Searching for ADT patterns with elem and find References: <3CDFB8AFEA98E34CB599475AB11589C80CCADB@EX2.ad.dcs.gla.ac.uk> <78dc001e0811120439o51baf362m25c50f85f3d7f364@mail.gmail.com> Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80CCAE5@EX2.ad.dcs.gla.ac.uk> Thanks Tom, That is indeed a very elegant solution; I too often forget about the wonders of list comprehension. I guess one drawback compared to Neil's suggested use of "any" (and staying with a separate "isTypeB") is that your solution will iterate over the entire list, regardless of an early hit. But I don't think your second (as-pattern) solution for findBs is ugly; I quite like it actually. Cheers, Paul -----Original Message----- From: Tom Nielsen [mailto:tanielsen@gmail.com] Sent: Wed 12/11/2008 12:39 To: Paul Keir Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Searching for ADT patterns with elem and find somebody pointed out a few months back that list comprehensions do this nicely: containsTypeB ts = not $ null [x | (B x) <- ts] no need for defining isTypeB. not quite sure how you would write findBs :: [T]->[T] succinctly; maybe findBs ts = [b | b@(B _) <- ts] or findBs ts = [B x | (B x) <- ts] both of them compile but the first is ugly and the second is inefficient (Tags a new T for every hit). Tom 2008/11/12 Paul Keir : > Hi All, > > If I have an ADT, say > > data T > = A String Integer > | B Double > | C > deriving(Eq) > > and I want to find if a list (ts) of type T contains an element of subtype > "B Double", must my "containsTypeX" function use a second "isTypeX" function > as follows: > > isTypeB :: T -> Bool > isTypeB (B _) = True > isTypeB _ = False > > containsTypeB :: [T] -> Bool > containsTypeB ts = maybe False (\x -> True) (find isTypeB ts) > > I understand that while something like "find C ts" will work, "find (isTypeB > _) ts" will not, but is there no such thing as a pattern combinator(?), or > lambda that could help with this situation. I find I have many individual > "isTypeB" functions now. > > Regards, > Paul > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081112/fb7b75c4/attachment.htm From neil.mitchell.2 at credit-suisse.com Wed Nov 12 08:45:05 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Wed Nov 12 08:40:58 2008 Subject: [Haskell-cafe] Searching for ADT patterns with elem and find In-Reply-To: <78dc001e0811120439o51baf362m25c50f85f3d7f364@mail.gmail.com> References: <3CDFB8AFEA98E34CB599475AB11589C80CCADB@EX2.ad.dcs.gla.ac.uk> <78dc001e0811120439o51baf362m25c50f85f3d7f364@mail.gmail.com> Message-ID: > containsTypeB ts = not $ null [x | (B x) <- ts] No need for the brackets on the left of the <-: not $ null [x | B x <- ts] > findBs ts = [b | b@(B _) <- ts] > > or > > findBs ts = [B x | (B x) <- ts] > > both of them compile but the first is ugly and the second is > inefficient (Tags a new T for every hit). If optimised does it really create a new B tag for each node? That seems like something that could be optimised away by the compiler. Either way, the difference is probably minimal. (There may be possible space leaks if the compiler did share the B, but I can't think of any off hand) Thanks Neil > > > 2008/11/12 Paul Keir : > > Hi All, > > > > If I have an ADT, say > > > > data T > > = A String Integer > > | B Double > > | C > > deriving(Eq) > > > > and I want to find if a list (ts) of type T contains an element of > > subtype "B Double", must my "containsTypeX" function use a second > > "isTypeX" function as follows: > > > > isTypeB :: T -> Bool > > isTypeB (B _) = True > > isTypeB _ = False > > > > containsTypeB :: [T] -> Bool > > containsTypeB ts = maybe False (\x -> True) (find isTypeB ts) > > > > I understand that while something like "find C ts" will work, "find > > (isTypeB > > _) ts" will not, but is there no such thing as a pattern > > combinator(?), or lambda that could help with this > situation. I find I > > have many individual "isTypeB" functions now. > > > > Regards, > > Paul > > > > _______________________________________________ > > 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 > > ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From neil.mitchell.2 at credit-suisse.com Wed Nov 12 08:47:59 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Wed Nov 12 08:47:54 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: References: <491AABE9.5070700@nobugs.org> <491AAE39.9090005@jellybean.co.uk> <7ca3f0160811120439j58ca666bxc950456330493022@mail.gmail.com> Message-ID: > It's possible that there's some more direct approach that > represents types as some kind of runtime values, but nobody > (to my knowledge) has done that. It don't think its possible - I tried it and failed. Consider: show (f []) Where f has the semantics of id, but has either the return type [Int] or [Char] - you get different results. Without computing the types everywhere, I don't see how you can determine the precise type of []. Thanks Neil > On Wed, Nov 12, 2008 at 12:39 PM, Luke Palmer > wrote: > > On Wed, Nov 12, 2008 at 3:21 AM, Jules Bean > wrote: > >> Andrew Birkett wrote: > >>> > >>> Hi, > >>> > >>> Is a formal proof that the Haskell language is > referentially transparent? > >>> Many people state "haskell is RT" without backing up > that claim. I > >>> know that, in practice, I can't write any counter-examples but > >>> that's a bit handy-wavy. Is there a formal proof that, for all > >>> possible haskell programs, we can replace coreferent expressions > >>> without changing the meaning of a program? > >> > >> The (well, a natural approach to a) formal proof would be > to give a > >> formal semantics for haskell. > > > > Haskell 98 does not seem that big to me (it's not teeny, but it's > > nothing like C++), yet we are continually embarrassed about > not having > > any formal semantics. What are the challenges preventing its > > creation? > > > > Luke > > _______________________________________________ > > 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 > > ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From neil.mitchell.2 at credit-suisse.com Wed Nov 12 08:53:12 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Wed Nov 12 08:48:42 2008 Subject: [Haskell-cafe] Searching for ADT patterns with elem and find In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CCAE5@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CCADB@EX2.ad.dcs.gla.ac.uk> <78dc001e0811120439o51baf362m25c50f85f3d7f364@mail.gmail.com> <3CDFB8AFEA98E34CB599475AB11589C80CCAE5@EX2.ad.dcs.gla.ac.uk> Message-ID: > I guess one drawback compared to Neil's suggested use of "any" (and staying with a separate "isTypeB") is that your solution will iterate over the entire list, regardless of an early hit. Nope, it will stop on the first one - Haskell is lazy like that :-) Thanks, Neil ________________________________ From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Paul Keir Sent: 12 November 2008 1:45 pm To: Tom Nielsen Cc: haskell-cafe@haskell.org Subject: RE: [Haskell-cafe] Searching for ADT patterns with elem and find Thanks Tom, That is indeed a very elegant solution; I too often forget about the wonders of list comprehension. I guess one drawback compared to Neil's suggested use of "any" (and staying with a separate "isTypeB") is that your solution will iterate over the entire list, regardless of an early hit. But I don't think your second (as-pattern) solution for findBs is ugly; I quite like it actually. Cheers, Paul -----Original Message----- From: Tom Nielsen [mailto:tanielsen@gmail.com] Sent: Wed 12/11/2008 12:39 To: Paul Keir Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Searching for ADT patterns with elem and find somebody pointed out a few months back that list comprehensions do this nicely: containsTypeB ts = not $ null [x | (B x) <- ts] no need for defining isTypeB. not quite sure how you would write findBs :: [T]->[T] succinctly; maybe findBs ts = [b | b@(B _) <- ts] or findBs ts = [B x | (B x) <- ts] both of them compile but the first is ugly and the second is inefficient (Tags a new T for every hit). Tom 2008/11/12 Paul Keir : > Hi All, > > If I have an ADT, say > > data T > = A String Integer > | B Double > | C > deriving(Eq) > > and I want to find if a list (ts) of type T contains an element of subtype > "B Double", must my "containsTypeX" function use a second "isTypeX" function > as follows: > > isTypeB :: T -> Bool > isTypeB (B _) = True > isTypeB _ = False > > containsTypeB :: [T] -> Bool > containsTypeB ts = maybe False (\x -> True) (find isTypeB ts) > > I understand that while something like "find C ts" will work, "find (isTypeB > _) ts" will not, but is there no such thing as a pattern combinator(?), or > lambda that could help with this situation. I find I have many individual > "isTypeB" functions now. > > Regards, > Paul > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081112/2e1b55e7/attachment.htm From tom.davie at gmail.com Wed Nov 12 09:03:15 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Wed Nov 12 08:57:45 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: References: <491AABE9.5070700@nobugs.org> <491AAE39.9090005@jellybean.co.uk> <7ca3f0160811120439j58ca666bxc950456330493022@mail.gmail.com> Message-ID: On 12 Nov 2008, at 14:47, Mitchell, Neil wrote: > >> It's possible that there's some more direct approach that >> represents types as some kind of runtime values, but nobody >> (to my knowledge) has done that. > > It don't think its possible - I tried it and failed. > > Consider: > > show (f []) > > Where f has the semantics of id, but has either the return type > [Int] or > [Char] - you get different results. Without computing the types > everywhere, I don't see how you can determine the precise type of []. Surely all this means is that part of the semantics of Haskell is the semantics of the type system -- isn't this expected? Bob From arnarbi at gmail.com Wed Nov 12 09:21:17 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Wed Nov 12 09:15:45 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: References: <1226399902.6496.9.camel@rubix.office.last.fm> Message-ID: <28012bc60811120621n5194a32am1f2e298cc49f4232@mail.gmail.com> Hi Reinier, On Wed, Nov 12, 2008 at 14:22, Reinier Lamers wrote: > Also, in my experience Haskell is not so good at data structures where > you can't do structural recursion easily, like graphs. In such cases > you want a language with easy pointers and destructive updates. You > can do those things in pure Haskell by using > the ST monad, but the code will be more verbose than in Java or C++, > and it will occasionally drive you insane with type messages like the > above (You thought you could use '$' freely instead of application? > Wrong!). Can you give examples of what you mean and why algebraic data types are not sufficient? In my research most things are "structurally recursive" and it was because Haskell is so good at such things that I started using it. cheers, Arnar From martin.sulzmann at gmail.com Wed Nov 12 09:26:50 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Wed Nov 12 09:21:21 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: References: <491AABE9.5070700@nobugs.org> <491AAE39.9090005@jellybean.co.uk> <7ca3f0160811120439j58ca666bxc950456330493022@mail.gmail.com> Message-ID: <491AE7AA.4000607@gmail.com> Lennart Augustsson wrote: > You can't write a straightforward dynamic semantics (in, say, > denotational style) for Haskell. > The problem is that with type classes you need to know the types > compute the values. > You could use a two step approach: first make a static semantics that > does type inference/checking and translates Haskell into a different > form that has resolved all overloading. > And, secondly, you can write a dynamic semantics for that language. > > But since the semantics has to have the type inference engine inside > it, it's going to be a pain. > > It's possible that there's some more direct approach that represents > types as some kind of runtime values, but nobody (to my knowledge) has > done that. > > This has been done. For example, check out the type class semantics given in Thatte, Semantics of type classes revisited, LFP '94 Stuckey and Sulzmann, A Theory of Overloading, TOPLAS'05 Harrison: A Simple Semantics for Polymorphic Recursion. APLAS 2005 is also related I think. The ICFP'08 poster Unified Type Checking for Type Classes and Type Families , Tom Schrijvers and Martin Sulzmann suggests that a type-passing semantics can even be programmed by (mis)using type families. - Martin > -- Lennart > > On Wed, Nov 12, 2008 at 12:39 PM, Luke Palmer wrote: > >> On Wed, Nov 12, 2008 at 3:21 AM, Jules Bean wrote: >> >>> Andrew Birkett wrote: >>> >>>> Hi, >>>> >>>> Is a formal proof that the Haskell language is referentially transparent? >>>> Many people state "haskell is RT" without backing up that claim. I know >>>> that, in practice, I can't write any counter-examples but that's a bit >>>> handy-wavy. Is there a formal proof that, for all possible haskell >>>> programs, we can replace coreferent expressions without changing the meaning >>>> of a program? >>>> >>> The (well, a natural approach to a) formal proof would be to give a formal >>> semantics for haskell. >>> >> Haskell 98 does not seem that big to me (it's not teeny, but it's >> nothing like C++), yet we are continually embarrassed about not having >> any formal semantics. What are the challenges preventing its >> creation? >> >> Luke >> _______________________________________________ >> 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 jake at pikewerks.com Wed Nov 12 09:31:19 2008 From: jake at pikewerks.com (Jake Mcarthur) Date: Wed Nov 12 09:25:49 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: References: <491AABE9.5070700@nobugs.org> <491AAE39.9090005@jellybean.co.uk> <7ca3f0160811120439j58ca666bxc950456330493022@mail.gmail.com> Message-ID: <1ADC580A-5F1E-4A29-9DCC-07595EF75B5C@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 12, 2008, at 7:09 AM, Lennart Augustsson wrote: > It's possible that there's some more direct approach that represents > types as some kind of runtime values, but nobody (to my knowledge) has > done that. I think JHC passes types at runtime, using them in C switch statements for overloading, but I don't know if an implementation like that is really what we would need for this. - - Jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkka6LcACgkQye5hVyvIUKnlfwCgmpcvghHK9lYd3XwK7sfwARnM xlYAoLXxw3sz4CNaThaNV9GGsX4ALR/L =0q26 -----END PGP SIGNATURE----- From lennart at augustsson.net Wed Nov 12 09:56:59 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Nov 12 09:51:27 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: <491AE7AA.4000607@gmail.com> References: <491AABE9.5070700@nobugs.org> <491AAE39.9090005@jellybean.co.uk> <7ca3f0160811120439j58ca666bxc950456330493022@mail.gmail.com> <491AE7AA.4000607@gmail.com> Message-ID: I had a quick look at "Stuckey and Sulzmann, A Theory of Overloading" and it looks to me like the semantics is given by evidence translation. So first you do evidence translation, and then give semantics to the translated program. So this looks like the two step approach I first mentioned. Or have I misunderstood what you're doing? What I meant hasn't been done is a one step semantics directly in terms of the source language. I guess I also want it to be compositional, which I think is where things break down. -- Lennart On Wed, Nov 12, 2008 at 2:26 PM, Martin Sulzmann wrote: > Lennart Augustsson wrote: >> >> You can't write a straightforward dynamic semantics (in, say, >> denotational style) for Haskell. >> The problem is that with type classes you need to know the types >> compute the values. >> You could use a two step approach: first make a static semantics that >> does type inference/checking and translates Haskell into a different >> form that has resolved all overloading. >> And, secondly, you can write a dynamic semantics for that language. >> >> But since the semantics has to have the type inference engine inside >> it, it's going to be a pain. >> >> It's possible that there's some more direct approach that represents >> types as some kind of runtime values, but nobody (to my knowledge) has >> done that. >> >> > > This has been done. For example, check out the type class semantics given in > > Thatte, Semantics of type classes revisited, LFP '94 > Stuckey and Sulzmann, A Theory of Overloading, TOPLAS'05 > > Harrison: A Simple Semantics for Polymorphic Recursion. APLAS 2005 > is also related I think. > > The ICFP'08 poster > > Unified Type Checking for Type Classes and Type Families , Tom Schrijvers > and Martin Sulzmann > > suggests that a type-passing semantics can even be programmed by (mis)using > type families. > > - Martin > > >> -- Lennart >> >> On Wed, Nov 12, 2008 at 12:39 PM, Luke Palmer wrote: >> >>> >>> On Wed, Nov 12, 2008 at 3:21 AM, Jules Bean >>> wrote: >>> >>>> >>>> Andrew Birkett wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> Is a formal proof that the Haskell language is referentially >>>>> transparent? >>>>> Many people state "haskell is RT" without backing up that claim. I >>>>> know >>>>> that, in practice, I can't write any counter-examples but that's a bit >>>>> handy-wavy. Is there a formal proof that, for all possible haskell >>>>> programs, we can replace coreferent expressions without changing the >>>>> meaning >>>>> of a program? >>>>> >>>> >>>> The (well, a natural approach to a) formal proof would be to give a >>>> formal >>>> semantics for haskell. >>>> >>> >>> Haskell 98 does not seem that big to me (it's not teeny, but it's >>> nothing like C++), yet we are continually embarrassed about not having >>> any formal semantics. What are the challenges preventing its >>> creation? >>> >>> Luke >>> _______________________________________________ >>> 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 igloo at earth.li Wed Nov 12 10:25:13 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Nov 12 10:19:47 2008 Subject: [Haskell-cafe] problem with boolean splicing in templates in ghc 6.10.1 In-Reply-To: <1226434581.17406.13.camel@functor.uta.edu> References: <1226434581.17406.13.camel@functor.uta.edu> Message-ID: <20081112152513.GA32035@matrix.chaos.earth.li> On Tue, Nov 11, 2008 at 02:16:21PM -0600, Leonidas Fegaras wrote: > Seems that boolean splicing in haskell templates in ghc 6.10.1 does not > work correctly. If you do: > > $((\b -> [| b |]) True) > > you get the error: > > Can't find interface-file declaration for data constructor GHC.Base.True > Probable cause: bug in .hi-boot file, or inconsistent .hi file > Use -ddump-if-trace to get an idea of which file caused the error > > It seems that GHC.Base.True is now GHC.Bool.True, but the splicing code > still generates the former. Fixed in HEAD and 6.10 branch, and I've added a test to the testsuite. If you want to build a fixed template-haskell package locally then the fix is: hunk ./Language/Haskell/TH/Syntax.hs 264 -trueName = mkNameG DataName "base" "GHC.Base" "True" -falseName = mkNameG DataName "base" "GHC.Base" "False" +trueName = mkNameG DataName "ghc-prim" "GHC.Bool" "True" +falseName = mkNameG DataName "ghc-prim" "GHC.Bool" "False" Thanks Ian From lists at qseep.net Wed Nov 12 11:10:57 2008 From: lists at qseep.net (Lyle Kopnicky) Date: Wed Nov 12 11:05:25 2008 Subject: [Haskell-cafe] TimeDiff to Int? Message-ID: <670e468e0811120810g26481a76tb1dddf274c11fa0f@mail.gmail.com> Hi folks, I had some code using the oldtime package, and want to convert it to use the time package. One of the things I need to do is calculate the number of seconds since midnight. The easy part is getting a TimeDiff result: utc <- getCurrentTime tz <- getCurrentTimeZone let td = timeOfDayToTime $ localTimeOfDay $ utcToLocalTime tz utc Now td is a TimeDiff representation of the number of seconds since midnight. It prints nicely, but I'm having a heck of a time figuring out how to truncate it to an Int. The floor function is only supported by the RealFrac class. Although TimeDiff has an instance of RealFrac and Fractional, it doesn't have an instance of RealFrac. I looked up the various to* and from* functions and have come up short. fromEnum yields an Int but it's the wrong value. I know I could use show and then use readS to get an Integer, or use formatTime (and reparse that), but that's a hack. I can convert it to a TimeOfDay which gives me hours, minutes, and seconds, but then I have to do arithmetic on it, and the seconds are of type Pico, which I can't call floor on either. I can convert it to a Rational via timeOfDayToDayFraction, but a TimeDiff is already a Rational those don't have floor. What am I missing? There has got to be an easy way to count seconds! Thanks, Lyle -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081112/9e5c7588/attachment.htm From hpacheco at gmail.com Wed Nov 12 11:14:48 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Wed Nov 12 11:09:16 2008 Subject: [Haskell-cafe] Hackage web interface Message-ID: <7b92c2840811120814h4486c9fcu242fa97b508ea8e@mail.gmail.com> Hi, When previewing some package via the Hackage web interface, I get the following warning: Exposed modules use unallocated top-level names: AI assume that if you define some module A.B, it expects the top-level name A to be a module. Does this make sense? Thanks, hugo -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081112/02ea3c89/attachment.htm From allbery at ece.cmu.edu Wed Nov 12 11:31:02 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Nov 12 11:25:39 2008 Subject: [Haskell-cafe] abstract extensible types? In-Reply-To: References: Message-ID: On 2008 Nov 12, at 5:38, Alberto G. Corona wrote: > Is there any abstract container that permits the addition of new > types of data? I know how to simulate the extension of Algebraic > datatypes, but this does not permit the addition of data with new > types in the same container and recover them in a type-safe way. > > Did I reinvent the Weel? I found something, that permits this for > any Typeable datatype. For example I think you want http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Dynamic.html . -- 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/20081112/efc59df2/attachment.htm From martin.sulzmann at gmail.com Wed Nov 12 11:36:02 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Wed Nov 12 11:30:35 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: References: <491AABE9.5070700@nobugs.org> <491AAE39.9090005@jellybean.co.uk> <7ca3f0160811120439j58ca666bxc950456330493022@mail.gmail.com> <491AE7AA.4000607@gmail.com> Message-ID: <491B05F2.4030809@gmail.com> Correct Lennart. The below mentioned papers assume some evidence translation of type class programs. If you need/want a direct semantics/translation of programs you'll need to impose some restrictions on the set of allowable type class programs. For such an approach see Martin Odersky, Philip Wadler, Martin Wehr: A Second Look at Overloading. FPCA 1995: Roughly, the restriction says, you can overload the argument but not the result (types). - Martin Lennart Augustsson wrote: > I had a quick look at "Stuckey and Sulzmann, A Theory of Overloading" > and it looks to me like the semantics is given by evidence > translation. So first you do evidence translation, and then give > semantics to the translated program. So this looks like the two step > approach I first mentioned. > Or have I misunderstood what you're doing? > > What I meant hasn't been done is a one step semantics directly in > terms of the source language. > I guess I also want it to be compositional, which I think is where > things break down. > > -- Lennart > > On Wed, Nov 12, 2008 at 2:26 PM, Martin Sulzmann > wrote: > >> Lennart Augustsson wrote: >> >>> You can't write a straightforward dynamic semantics (in, say, >>> denotational style) for Haskell. >>> The problem is that with type classes you need to know the types >>> compute the values. >>> You could use a two step approach: first make a static semantics that >>> does type inference/checking and translates Haskell into a different >>> form that has resolved all overloading. >>> And, secondly, you can write a dynamic semantics for that language. >>> >>> But since the semantics has to have the type inference engine inside >>> it, it's going to be a pain. >>> >>> It's possible that there's some more direct approach that represents >>> types as some kind of runtime values, but nobody (to my knowledge) has >>> done that. >>> >>> >>> >> This has been done. For example, check out the type class semantics given in >> >> Thatte, Semantics of type classes revisited, LFP '94 >> Stuckey and Sulzmann, A Theory of Overloading, TOPLAS'05 >> >> Harrison: A Simple Semantics for Polymorphic Recursion. APLAS 2005 >> is also related I think. >> >> The ICFP'08 poster >> >> Unified Type Checking for Type Classes and Type Families , Tom Schrijvers >> and Martin Sulzmann >> >> suggests that a type-passing semantics can even be programmed by (mis)using >> type families. >> >> - Martin >> >> >> >>> -- Lennart >>> >>> On Wed, Nov 12, 2008 at 12:39 PM, Luke Palmer wrote: >>> >>> >>>> On Wed, Nov 12, 2008 at 3:21 AM, Jules Bean >>>> wrote: >>>> >>>> >>>>> Andrew Birkett wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> Is a formal proof that the Haskell language is referentially >>>>>> transparent? >>>>>> Many people state "haskell is RT" without backing up that claim. I >>>>>> know >>>>>> that, in practice, I can't write any counter-examples but that's a bit >>>>>> handy-wavy. Is there a formal proof that, for all possible haskell >>>>>> programs, we can replace coreferent expressions without changing the >>>>>> meaning >>>>>> of a program? >>>>>> >>>>>> >>>>> The (well, a natural approach to a) formal proof would be to give a >>>>> formal >>>>> semantics for haskell. >>>>> >>>>> >>>> Haskell 98 does not seem that big to me (it's not teeny, but it's >>>> nothing like C++), yet we are continually embarrassed about not having >>>> any formal semantics. What are the challenges preventing its >>>> creation? >>>> >>>> Luke >>>> _______________________________________________ >>>> 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 philip.weaver at gmail.com Wed Nov 12 12:43:33 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Wed Nov 12 12:38:02 2008 Subject: [Haskell-cafe] TimeDiff to Int? In-Reply-To: <670e468e0811120810g26481a76tb1dddf274c11fa0f@mail.gmail.com> References: <670e468e0811120810g26481a76tb1dddf274c11fa0f@mail.gmail.com> Message-ID: 2008/11/12 Lyle Kopnicky > Hi folks, > > I had some code using the oldtime package, and want to convert it to use > the time package. > > One of the things I need to do is calculate the number of seconds since > midnight. The easy part is getting a TimeDiff result: > > utc <- getCurrentTime > tz <- getCurrentTimeZone > let td = timeOfDayToTime $ localTimeOfDay $ utcToLocalTime tz utc > > Now td is a TimeDiff representation of the number of seconds since > midnight. It prints nicely, but I'm having a heck of a time figuring out how > to truncate it to an Int. > > The floor function is only supported by the RealFrac class. Although > TimeDiff has an instance of RealFrac and Fractional, it doesn't have an > instance of RealFrac. I looked up the various to* and from* functions and > have come up short. fromEnum yields an Int but it's the wrong value. I know > I could use show and then use readS to get an Integer, or use formatTime > (and reparse that), but that's a hack. > > I can convert it to a TimeOfDay which gives me hours, minutes, and seconds, > but then I have to do arithmetic on it, and the seconds are of type Pico, > which I can't call floor on either. I can convert it to a Rational via > timeOfDayToDayFraction, but a TimeDiff is already a Rational those don't > have floor. > > What am I missing? There has got to be an easy way to count seconds! > Well, you could always (read . takeWhile (not . (=='.')) . show), but here's a better way: let x = toRational td in numerator x `div` denominator x This was just the first thing I could come up with. I bet there's a nicer way. - Phil > Thanks, > Lyle > > > _______________________________________________ > 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/20081112/a965045b/attachment.htm From ddssff at gmail.com Wed Nov 12 12:46:05 2008 From: ddssff at gmail.com (David Fox) Date: Wed Nov 12 12:40:38 2008 Subject: [Haskell-cafe] Turning all the Nothings into Just defaultValue using Data.Generics Message-ID: I want to use Data.Generics to write a function to turn all the Nothings in a data structure into Just defaultValue, as shown below. I get the following error because the compiler doesn't know enough about Maybe a for mkT to create the generic function that everywhere requires, I guess. Test.hs:26:16: Ambiguous type variable `a' in the constraints: `Typeable a' arising from a use of `mkT' at Senior/Test2.hs:26:16-30 `Default a' arising from a use of `justDefault' at Senior/Test2.hs:26:20-30 Probable fix: add a type signature that fixes these type variable(s) Here is the example. It all works except for "test". Any suggestions how to do this? {-# LANGUAGE DeriveDataTypeable, FlexibleContexts, FlexibleInstances, MultiParamTypeClasses, RankNTypes, TemplateHaskell, TypeSynonymInstances #-} {-# OPTIONS_GHC -fallow-undecidable-instances #-} module Test where import Data.Generics class Default a where defaultValue :: a instance Default Int where defaultValue = 0 instance Default String where defaultValue = "" instance Default (Maybe a) where defaultValue = Nothing data A = A {b :: Int, c :: Maybe String} deriving (Show, Data, Typeable) instance Default A where defaultValue = A {b = defaultValue, c = defaultValue} test = everywhere (mkT justDefault) (defaultValue :: A) where justDefault Nothing = Just defaultValue justDefault (Just x) = Just x -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081112/91292b10/attachment.htm From ross at soi.city.ac.uk Wed Nov 12 12:57:15 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Nov 12 12:51:44 2008 Subject: [Haskell-cafe] Hackage web interface In-Reply-To: <7b92c2840811120814h4486c9fcu242fa97b508ea8e@mail.gmail.com> References: <7b92c2840811120814h4486c9fcu242fa97b508ea8e@mail.gmail.com> Message-ID: <20081112175715.GA6239@soi.city.ac.uk> On Wed, Nov 12, 2008 at 04:14:48PM +0000, Hugo Pacheco wrote: > When previewing some package via the Hackage web interface, I get the following > warning: > Exposed modules use unallocated top-level names: A > I assume that if you define some module A.B, it expects the top-level name A to > be a module. Not a module, but one of a few names. See http://www.haskell.org/haskellwiki/Hierarchical_module_names From derek.a.elkins at gmail.com Wed Nov 12 13:20:16 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Wed Nov 12 13:14:51 2008 Subject: [Haskell-cafe] Searching for ADT patterns with elem and find In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CCADB@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CCADB@EX2.ad.dcs.gla.ac.uk> Message-ID: <1226514016.15731.3.camel@derek-laptop> On Wed, 2008-11-12 at 10:09 +0000, Paul Keir wrote: > Hi All, > > If I have an ADT, say > > data T > = A String Integer > | B Double > | C > deriving(Eq) > > and I want to find if a list (ts) of type T contains an element of > subtype "B Double", must my "containsTypeX" function use a second > "isTypeX" function as follows: > > isTypeB :: T -> Bool > isTypeB (B _) = True > isTypeB _ = False > > containsTypeB :: [T] -> Bool > containsTypeB ts = maybe False (\x -> True) (find isTypeB ts) > > I understand that while something like "find C ts" will work, "find > (isTypeB _) ts" will not, but is there no such thing as a pattern > combinator(?), or lambda that could help with this situation. I find I > have many individual "isTypeB" functions now. > In addition to what others have said, I recommend using functions like isTypeB :: T -> Maybe Double isTypeB (B d) = Just d isTypeB _ = Nothing You can recover the Bool version of isTypeB just by post-composing with isJust, but this version avoids needing partial functions and often is more what you want (i.e. it's a first-class "pattern"). Combining it with catMaybes is also a common pattern. From ryani.spam at gmail.com Wed Nov 12 13:26:19 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Nov 12 13:20:46 2008 Subject: [Haskell-cafe] abstract extensible types? In-Reply-To: References: Message-ID: <2f9b2d30811121026y3ff92434q77c088df1d8477f7@mail.gmail.com> http://www.cs.nott.ac.uk/~wss/Publications/DataTypesALaCarte.pdf This lets you create sets of types to store in a container, with the static guarantee that only members of the set of types are included. The types can contain other elements of the set within them recursively. To extract value from the container, you can provide observation algebras that work on subsets of these values. It's a great solution to this problem and avoids the "anything with Typeable" issue that you get using Dynamic, which adds lots of run-time failure cases if something you didn't expect makes it into your data. -- ryan 2008/11/12 Alberto G. Corona : > Is there any abstract container that permits the addition of new types of > data? I know how to simulate the extension of Algebraic datatypes, but this > does not permit the addition of data with new types in the same container > and recover them in a type-safe way. > > Did I reinvent the Weel? I found something, that permits this for any > Typeable datatype. For example > > > x=5 > list= [put x, put "hello"] > > [t1,t2 ]= list > > x' = get t1 :: Int > s = get t2 :: String > print (x' +1) -- 2 > print s -- "hello" > > x''= get t2 :: Int --"get: casting from String to type Int" > > > > The code: > > data Abstract= forall a. Typeable a => T !String a > > > class FromToAbstract x where > put :: x -> Abstract > get :: Abstract -> x > unsafeGet :: Abstract -> x > > -- get(put x)== x > > instance Typeable x => FromToAbstract x where > put x= T (typeString x) x > > get (Abstract type1 a)= if type2 == type1 then v > else error ("get: casting "++ "from type "++type1++" > to type "++type2) > where > v= unsafeCoerce a :: x > type2= typeString v > > unsafeGet (Abstract type1 a)= unsafeCoerce a > > > typeString !x= tyConString $ typeRepTyCon $ typeOf x > > instance Typeable T where > typeOf _= mkTyConApp (mkTyCon "Abstract") [] > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From ryani.spam at gmail.com Wed Nov 12 13:31:36 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Nov 12 13:26:03 2008 Subject: [Haskell-cafe] Searching for ADT patterns with elem and find In-Reply-To: <1226514016.15731.3.camel@derek-laptop> References: <3CDFB8AFEA98E34CB599475AB11589C80CCADB@EX2.ad.dcs.gla.ac.uk> <1226514016.15731.3.camel@derek-laptop> Message-ID: <2f9b2d30811121031m5f39b97cwd6e719b12b355678@mail.gmail.com> On Wed, Nov 12, 2008 at 10:20 AM, Derek Elkins wrote: > In addition to what others have said, I recommend using functions like > isTypeB :: T -> Maybe Double > isTypeB (B d) = Just d > isTypeB _ = Nothing > > You can recover the Bool version of isTypeB just by post-composing with > isJust, but this version avoids needing partial functions and often is > more what you want (i.e. it's a first-class "pattern"). Combining it > with catMaybes is also a common pattern. Although if you are using Maybe as a monad, these two pieces of code are equivalent: test1 t1 t2 = do d1 <- isTypeB t1 d2 <- isTypeB t2 return (d1 + d2) test2 t1 t2 = do B d1 <- return t1 B d2 <- return t2 return (d1 + d2) This is because pattern-matching in do-notation implicitly calls "fail" when the pattern match fails. -- ryan From wren at freegeek.org Wed Nov 12 13:36:12 2008 From: wren at freegeek.org (wren ng thornton) Date: Wed Nov 12 13:30:40 2008 Subject: [Haskell-cafe] Searching for ADT patterns with elem and find In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CCADB@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CCADB@EX2.ad.dcs.gla.ac.uk> Message-ID: <491B221C.5040603@freegeek.org> Paul Keir wrote: > Hi All, > > If I have an ADT, say > > data T > = A String Integer > | B Double > | C > deriving(Eq) > > and I want to find if a list (ts) of type T contains an element of subtype "B Double", must my "containsTypeX" function use a second "isTypeX" function as follows: > > isTypeB :: T -> Bool > isTypeB (B _) = True > isTypeB _ = False > > containsTypeB :: [T] -> Bool > containsTypeB ts = maybe False (\x -> True) (find isTypeB ts) Many other good posts have obviated the original question, but just to answer it directly. You can turn isTypeB into a lambda by using a case expression: isTypeB = \t -> case t of B _ -> True ; _ -> False And from there you can just inline the definition in order to remove isTypeB. Pattern matching in function definitions is just sugar for the case expression version, so this transformation is just what the compiler would be doing anyways. -- Live well, ~wren From ryani.spam at gmail.com Wed Nov 12 13:47:22 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Nov 12 13:41:49 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: <491AABE9.5070700@nobugs.org> References: <491AABE9.5070700@nobugs.org> Message-ID: <2f9b2d30811121047h10582d4bq332ab174487ada52@mail.gmail.com> On a totally non-theory side, Haskell isn't referentially transparent. In particular, any code that calls unsafePerformIO or unsafeInterleaveIO is not necessarily RT. Given that getContents and interact use unsafeInterleaveIO, this includes most toy programs as well as almost every non-toy program; almost all use unsafePerformIO intentionally. That said, the situations in which these functions are RT are not that hard to meet, but they would muddy up any formal proof significantly. Personally, I'm happy with the hand-wavy proof that goes like this: 1) "pure" functions don't have side effects. 2) side-effect free functions can be duplicated or shared without affecting the results of the program that uses them (in the absence of considerations of resource limitation like running out of memory) 3) any function that only uses other pure functions is pure 4) all Haskell98 functions that don't use unsafe* are pure 5) therefore Haskell98 minus unsafe functions is referentially transparent. Note that I am including I/O actions as "pure" when observed as the GHC implementation of IO a ~~ World -> (World, a); the function result that is the value of "main" is pure. It is only the observation of that function by the runtime that causes side effects. -- ryan On Wed, Nov 12, 2008 at 2:11 AM, Andrew Birkett wrote: > Hi, > > Is a formal proof that the Haskell language is referentially transparent? > Many people state "haskell is RT" without backing up that claim. I know > that, in practice, I can't write any counter-examples but that's a bit > handy-wavy. Is there a formal proof that, for all possible haskell > programs, we can replace coreferent expressions without changing the meaning > of a program? > > (I was writing a blog post about the origins of the phrase 'referentially > transparent' and it made me think about this) > > Andrew > > -- > - http://www.nobugs.org - > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dons at galois.com Wed Nov 12 13:50:40 2008 From: dons at galois.com (Don Stewart) Date: Wed Nov 12 13:45:10 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: References: <1226399902.6496.9.camel@rubix.office.last.fm> Message-ID: <20081112185040.GI421@scytale.galois.com> tux_rocker: > 2008/11/11 Dave Tapley : > > So I should clarify I'm not a troll and do "see the Haskell light". But > > one thing I can never answer when preaching to others is "what does > > Haskell not do well?" > > Let's say something controversial: I think that Haskell's type system > gets in your way when you're writing one-shot scripts that don't need > to conform to the highest correctness standards. Imagine typing a > command at the shell prompt and getting the sort of abstract error > message that Haskell compilers give every now and then, like: > > > whyerror.lhs:36:25: > > Ambiguous type variable `a' in the constraint: > > `Arrow a' arising from use of `>>>' at whyerror.lhs:36:25-27 > > Possible cause: the monomorphism restriction applied to the > > following: > > liftA2' :: forall b a1 b1 c. (a1 -> b1 -> c) -> a b a1 -> a b > > b1 -> a b c > > (bound at whyerror.lhs:36:1) > > unsplit' :: forall a1 b c. (a1 -> b -> c) -> a (a1, b) c > > (bound at whyerror.lhs:34:1) > > split' :: forall b. a b (b, b) (bound at whyerror.lhs:33:1) > > Probable fix: give these definition(s) an explicit type signature > > or use -fno-monomorphism-restriction > > You don't want to be bothered by such monstrosities (yes, they are, > even though many of you may not see it because of years of > conditioning) when you're just hacking up a simple script to make a > catalog of your MP3 collection / check for patterns in log files / > whatever. Why are you using Arrows in your one shot scripts? Do you use Arrows in your shell scripts? Seems like a strawman argument.. -- Don From jonathanccast at fastmail.fm Wed Nov 12 14:03:59 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Nov 12 13:58:35 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <20081112185040.GI421@scytale.galois.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <20081112185040.GI421@scytale.galois.com> Message-ID: <1226516639.26242.18.camel@jcchost> On Wed, 2008-11-12 at 10:50 -0800, Don Stewart wrote: > tux_rocker: > > 2008/11/11 Dave Tapley : > > > So I should clarify I'm not a troll and do "see the Haskell light". But > > > one thing I can never answer when preaching to others is "what does > > > Haskell not do well?" > > > > Let's say something controversial: I think that Haskell's type system > > gets in your way when you're writing one-shot scripts that don't need > > to conform to the highest correctness standards. Imagine typing a > > command at the shell prompt and getting the sort of abstract error > > message that Haskell compilers give every now and then, like: > > > > > whyerror.lhs:36:25: > > > Ambiguous type variable `a' in the constraint: > > > `Arrow a' arising from use of `>>>' at whyerror.lhs:36:25-27 > > > Possible cause: the monomorphism restriction applied to the > > > following: > > > liftA2' :: forall b a1 b1 c. (a1 -> b1 -> c) -> a b a1 -> a b > > > b1 -> a b c > > > (bound at whyerror.lhs:36:1) > > > unsplit' :: forall a1 b c. (a1 -> b -> c) -> a (a1, b) c > > > (bound at whyerror.lhs:34:1) > > > split' :: forall b. a b (b, b) (bound at whyerror.lhs:33:1) > > > Probable fix: give these definition(s) an explicit type signature > > > or use -fno-monomorphism-restriction > > > > You don't want to be bothered by such monstrosities (yes, they are, > > even though many of you may not see it because of years of > > conditioning) when you're just hacking up a simple script to make a > > catalog of your MP3 collection / check for patterns in log files / > > whatever. > > Why are you using Arrows in your one shot scripts? Because a generic operator like (>>>) is a) More likely to exist, and b) easier to remember than a special case operator like --- actually, I don't think GHC does come with a standard version of (>>>) type-specialized to functions, only a version of (<<<). Or if it does, I can't remember it. > Do you use Arrows in > your shell scripts? I use pipelines. Frequently. I even type them up at the command line. Beyond that, I was considering the pipeline uses -l snippet_calculate\\b | perl -lne 'chomp; print $_ unless qx{svn st | grep $_}' (`uses' is a recursive grep-like shell function I have). The use of perl immediately suggested that it could profitably be re-written in Haskell (actually, in a similar FP language I've been designing --- not relevant); my translation included a line something like interactiveM $ filterM $ comp >>> \ x -> So yeah, I use arrows in my shell scripts. Who doesn't? (On the other hand, I'm actively designing an FP shell-like language...) jcc From benja.fallenstein at gmail.com Wed Nov 12 15:25:45 2008 From: benja.fallenstein at gmail.com (Benja Fallenstein) Date: Wed Nov 12 15:20:12 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: References: <491AABE9.5070700@nobugs.org> <491AAE39.9090005@jellybean.co.uk> <7ca3f0160811120439j58ca666bxc950456330493022@mail.gmail.com> Message-ID: Hi all, On Wed, Nov 12, 2008 at 2:09 PM, Lennart Augustsson wrote: > You can't write a straightforward dynamic semantics (in, say, > denotational style) for Haskell. > The problem is that with type classes you need to know the types > compute the values. ... > It's possible that there's some more direct approach that represents > types as some kind of runtime values, but nobody (to my knowledge) has > done that. It seems to me that if you don't need your semantics to do the work of type-*checking* (i.e., you don't care if the rules assign some strange denotation to an ill-typed term), there is a natural approach to giving semantics to 98-style type classes. I'm figuring out the details as I type, though; if anybody sees anything that does not work, please do tell! Let "type" mean a non-overloaded type expression (i.e., not containing variables). I'll suppose that you already know the set of types in the program and the domain associated with each type. (This is usual in denotational treatments, right?) Let the domains be such that all sets of elements have a join (i.e., complete lattices). Define the domain of "overloaded values" to be the domain of functions from types to values of these types or "bottom" (when I say "bottom" in the following, it is this bottom, which is below the domain's bottom), i.e., the product of the liftings of the domains of all possible types. The interpretation of "bottom" is, "this overloaded value doesn't have an instance at this type" (e.g., [7,9] is "bottom" at type Bool). An *environment* is a function from symbols to overloaded values. The denotation of an expression is a function from environments to overloaded values; the denotation of a definition list is a function from environments to environments; the denotation of a whole program is the least fixed point of the definition list that makes up the program. Expressions are interpreted as follows (update :: Symbol -> OverloadedValue -> Environment -> Environment is defined in the natural way): [[x]] = \env type. env "x" type [[T :: TYPE]] = \env type. if type instance of TYPE then [[T]] env type else bottom [[F X]] = Join_type2. \env type1. [[F]] env (type1 -> type2) $ [[X]] env type2 [[\x. T]] = \env type. case type of (type1 -> type2) -> \val. [[T]] (update "x" (mono type1 val) env) type2 otherwise -> bottom where mono ty val = \ty'. if ty == ty' then val else bottom [[let x=S in T]] = \env type. [[T]] (fix $ \env'. update "x" ([[S]] env') env) type Simple definitions are interpreted in the obvious way: [[x = T]] = \env sym. if sym == "x" then ([[T]] env) else (env sym) [[x :: Ty; x = T]] = [[x = T :: Ty]] Finally, instance declarations are interpreted in a special way. To interpret the declaration instance C Ty1 .. Tyn where ...; xi = Ti; ... we need to know the set of possible types for xi. (No type inference should be necessary -- the class declaration + the Ty1 .. Tyn from the instance declaration should give us all the necessary information, right?) Call this set Types. Then, [[xi = Ti]] = \env sym type. if sym == "xi" && type in Types then [[T]] env type else env sym type That is, an instance declaration sets the value of a symbol at some types, and leaves the values at the other types alone. Some notes: * If T is a well-typed term and type is *not* a type instance of that term, then ([[T]] env type) is bottom. * In particular, [[T :: TYPE]] env type = [[T]] env type, when type is an instance of TYPE; otherwise, [[T :: TYPE]] env type = bottom. * Application is supposed to be strict in "bottom": bottom x = bottom; f bottom = bottom. * In interpreting [[F X]], we take the join over all possible types of X ("type2"). If X is monomorphic, then ([[X]] env type2) is bottom for all types except the correct one, so the join gives the correct denotation. If X is polymorphic, but the type of F together with the type forced by the context of (F X) together determine what type of X must be used, then either ([[F]] env (type1 -> type2)) or ([[X]] env type2) will be bottom for every type2 exept for the one we want to use; so the application ([[F]] ... $ [[X]] ...) will be bottom except for the correct type; so again, the join will give the correct denotation. (Caveat lector: I haven't proved this, I'm running on intuition :)) * In the interpretation of expressions like (show (read "5")), the join is non-degenerate: it consists of the join of "5", "5.0" etc. But since such expressions are rejected by the type-checker, we don't care. * Lets containing multiple definitions can be translated as in the Haskell report, if we add an interpretation for a case construct (I'm too lazy to try): http://www.haskell.org/onlinereport/exps.html#sect3.12 * In the interpretation of the lambda expression, we need to interpret the body of the expression separately for every type of the lambda expression; the function 'mono' converts the monomorphic parameter value into an OverloadedValue that is bottom everywhere except at the monomorphic type. In the interpretation of 'let', and of top-level definitions, on the other hand, we don't have 'mono' -- we update the environment with an OverloadedValue. I was surprised to have the "lambda arguments are monomorphic" rule from the Hindley-Milner system forced upon me like that! :-) * Neil's example, (show (f [])) where either f = id :: [Int] -> [Int] or f = id :: [Char] -> [Char], is taken care of straight-forwardly. The interpretation of f = (id :: [Int] -> [Int]]) is bottom at all types except [Int] -> [Int]; therefore, (f []) is bottom at all types except [Int]; therefore, in the join over all possible types in the application (show (f [])), only the type ([Int] -> String) of show is actually used. Comments? Problems? [ I hope *somebody* is actually going to read this mail -- I don't have the time to make it less confusing, sorry :-( ] Thanks, - Benja -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081112/19dead3b/attachment.htm From lennart at augustsson.net Wed Nov 12 15:35:53 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Nov 12 15:30:20 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: <2f9b2d30811121047h10582d4bq332ab174487ada52@mail.gmail.com> References: <491AABE9.5070700@nobugs.org> <2f9b2d30811121047h10582d4bq332ab174487ada52@mail.gmail.com> Message-ID: Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. Since you are talking to the outside world any behaviour is acceptable. All the weird interactions between getContents and writing the same file from the same program could, in principle, happen if a different program wrote the file. The unsafePerformIO function can break RT, but I think everyone is aware of that. :) -- Lennart On Wed, Nov 12, 2008 at 6:47 PM, Ryan Ingram wrote: > On a totally non-theory side, Haskell isn't referentially transparent. > In particular, any code that calls unsafePerformIO or > unsafeInterleaveIO is not necessarily RT. Given that getContents and > interact use unsafeInterleaveIO, this includes most toy programs as > well as almost every non-toy program; almost all use unsafePerformIO > intentionally. > > That said, the situations in which these functions are RT are not that > hard to meet, but they would muddy up any formal proof significantly. > > Personally, I'm happy with the hand-wavy proof that goes like this: > > 1) "pure" functions don't have side effects. > 2) side-effect free functions can be duplicated or shared without > affecting the results of the program that uses them (in the absence of > considerations of resource limitation like running out of memory) > 3) any function that only uses other pure functions is pure > 4) all Haskell98 functions that don't use unsafe* are pure > 5) therefore Haskell98 minus unsafe functions is referentially transparent. > > Note that I am including I/O actions as "pure" when observed as the > GHC implementation of IO a ~~ World -> (World, a); the function result > that is the value of "main" is pure. It is only the observation of > that function by the runtime that causes side effects. > > -- ryan > > On Wed, Nov 12, 2008 at 2:11 AM, Andrew Birkett wrote: >> Hi, >> >> Is a formal proof that the Haskell language is referentially transparent? >> Many people state "haskell is RT" without backing up that claim. I know >> that, in practice, I can't write any counter-examples but that's a bit >> handy-wavy. Is there a formal proof that, for all possible haskell >> programs, we can replace coreferent expressions without changing the meaning >> of a program? >> >> (I was writing a blog post about the origins of the phrase 'referentially >> transparent' and it made me think about this) >> >> Andrew >> >> -- >> - http://www.nobugs.org - >> _______________________________________________ >> 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 monnier at iro.umontreal.ca Wed Nov 12 16:11:34 2008 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Wed Nov 12 16:06:09 2008 Subject: [Haskell-cafe] Re: What *not* to use Haskell for References: <1226399902.6496.9.camel@rubix.office.last.fm> Message-ID: > So I should clarify I'm not a troll and do "see the Haskell light". But > one thing I can never answer when preaching to others is "what does > Haskell not do well?" The most obvious cases where Haskell does not do well, for me: - When you feed it Java code. Incidentally, the same holds when you feed it C code. - When you try to write a malloc library. Stefan From ryani.spam at gmail.com Wed Nov 12 16:34:08 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Nov 12 16:28:35 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: References: <491AABE9.5070700@nobugs.org> <2f9b2d30811121047h10582d4bq332ab174487ada52@mail.gmail.com> Message-ID: <2f9b2d30811121334g5dc9daetece408688c2aded@mail.gmail.com> On Wed, Nov 12, 2008 at 12:35 PM, Lennart Augustsson wrote: > Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. > Since you are talking to the outside world any behaviour is acceptable. > All the weird interactions between getContents and writing the same > file from the same program could, in principle, happen if a different > program wrote the file. Yes, I was thinking about this on my way to work and thought that I may have spoken too soon; I couldn't come up with a way for unsafeInterleaveIO to break referential transparency (although I couldn't prove to myself that it couldn't, either). Your argument seems good to me, though. -- ryan From andrewcoppin at btinternet.com Wed Nov 12 16:51:14 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Nov 12 16:45:43 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <1226399902.6496.9.camel@rubix.office.last.fm> References: <1226399902.6496.9.camel@rubix.office.last.fm> Message-ID: <491B4FD2.1070900@btinternet.com> Dave Tapley wrote: > Hi everyone > > So I should clarify I'm not a troll and do "see the Haskell light". But > one thing I can never answer when preaching to others is "what does > Haskell not do well?" > > Usually I'll avoid then question and explain that it is a 'complete' > language and we do have more than enough libraries to make it useful and > productive. But I'd be keen to know if people have any anecdotes, > ideally ones which can subsequently be twisted into an argument for > Haskell ;) > Anything with hard performance requirements, and/or that needs to run on tiny computational resources (CPU speed, RAM size, etc.) I'd say "device drivers" too, except that the House guys apparently managed to do this... I'd really love to tell everybody that "Haskell is *the* language of algorithms" - except that it tends to not be very performant. Unfortunately, with the current state of the art, high-performance computer programs still require lots of low-level details to be explicitly managed. Hopefully one day this will cease to be the case. From andrewcoppin at btinternet.com Wed Nov 12 16:52:53 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Nov 12 16:47:19 2008 Subject: [Haskell-cafe] Interactive Message-ID: <491B5035.2030200@btinternet.com> I have a small question... Given that interactivity is Really Hard to do in Haskell, and that mutable state is to be strongly avoided, how come Frag exists? (I.e., how did they successfully solve these problems?) From flippa at flippac.org Wed Nov 12 16:54:54 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Wed Nov 12 16:49:27 2008 Subject: [Haskell-cafe] Interactive In-Reply-To: <491B5035.2030200@btinternet.com> References: <491B5035.2030200@btinternet.com> Message-ID: On Wed, 12 Nov 2008, Andrew Coppin wrote: > I have a small question... > > Given that interactivity is Really Hard to do in Haskell, and that mutable > state is to be strongly avoided, how come Frag exists? (I.e., how did they > successfully solve these problems?) > Because the givens are bull :-) That said, Frag doesn't throw too many different types of entities around and its performance isn't great when you look at the game simulation (largely because it was an experiment in using FRP). -- flippa@flippac.org A problem that's all in your head is still a problem. Brain damage is but one form of mind damage. From thomas.dubuisson at gmail.com Wed Nov 12 16:58:46 2008 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Wed Nov 12 16:53:13 2008 Subject: [Haskell-cafe] Interactive In-Reply-To: <491B5035.2030200@btinternet.com> References: <491B5035.2030200@btinternet.com> Message-ID: <4c44d90b0811121358t49bdda16j8d2a7d9a0fbd2c30@mail.gmail.com> Here are the links that hold the information you desire: http://www.haskell.org/haskellwiki/Frag http://www.cse.unsw.edu.au/~pls/thesis/munc-thesis.pdf In short: FRP http://www.haskell.org/frp/ On Wed, Nov 12, 2008 at 1:52 PM, Andrew Coppin wrote: > I have a small question... > > Given that interactivity is Really Hard to do in Haskell, and that mutable > state is to be strongly avoided, how come Frag exists? (I.e., how did they > successfully solve these problems?) > > _______________________________________________ > 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/20081112/8f4b27bd/attachment.htm From tomahawkins at gmail.com Wed Nov 12 17:01:19 2008 From: tomahawkins at gmail.com (Tom Hawkins) Date: Wed Nov 12 16:55:46 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <491969F4.6000300@jellybean.co.uk> References: <1226399902.6496.9.camel@rubix.office.last.fm> <491969F4.6000300@jellybean.co.uk> Message-ID: <594c1e830811121401m6624654h4c03dd50abf671b1@mail.gmail.com> On Tue, Nov 11, 2008 at 5:18 AM, Jules Bean wrote: > Dave Tapley wrote: >> >> Hi everyone >> >> So I should clarify I'm not a troll and do "see the Haskell light". But >> one thing I can never answer when preaching to others is "what does >> Haskell not do well?" > > GHC's scheduler lacks any hard timeliness guarantees. > > Thus it's quite hard to use haskell in realtime or even soft-realtime > environments. Actually, Haskell is an excellent language for hard real-time applications. At Eaton we're using it for automotive powertrain control. Of course, the RTS is not running in the loop. Instead, we write in a DSL, which generates C code for our vehicle ECU. Thanks to this great language, we traded 100K lines of Simulink for 3K lines of Haskell. Our current program is planned to hit the production lines in a few months. With similar methods, Haskell is also a great language for ASIC and FPGA design. -Tom From andy at nobugs.org Wed Nov 12 17:02:08 2008 From: andy at nobugs.org (Andrew Birkett) Date: Wed Nov 12 16:56:38 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: References: <491AABE9.5070700@nobugs.org> Message-ID: <491B5260.4030903@nobugs.org> Edsko de Vries wrote: > See "What is a purely functional language" by Sabry. Not quite a formal > proof about *Haskell*, but then we would first need a formal semantics > of Haskell to be able to do that proof ;-) Thanks for the reference, and also to everyone who replied - all very useful and interesting. For what it's worth, the blog posts I was writing are here: http://www.nobugs.org/blog/archives/2008/11/12/why-do-they-call-it-referentially-transparent/ http://www.nobugs.org/blog/archives/2008/11/12/why-do-they-call-it-referentially-transparent-ii/ Andrew From dons at galois.com Wed Nov 12 17:04:26 2008 From: dons at galois.com (Don Stewart) Date: Wed Nov 12 16:58:58 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <491B4FD2.1070900@btinternet.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <491B4FD2.1070900@btinternet.com> Message-ID: <20081112220426.GA1099@scytale.galois.com> andrewcoppin: > >So I should clarify I'm not a troll and do "see the Haskell light". But > >one thing I can never answer when preaching to others is "what does > >Haskell not do well?" > > > >Usually I'll avoid then question and explain that it is a 'complete' > >language and we do have more than enough libraries to make it useful and > >productive. But I'd be keen to know if people have any anecdotes, > >ideally ones which can subsequently be twisted into an argument for > >Haskell ;) > > Anything with hard performance requirements, and/or that needs to run on > tiny computational resources (CPU speed, RAM size, etc.) > > I'd say "device drivers" too, except that the House guys apparently > managed to do this... > > I'd really love to tell everybody that "Haskell is *the* language of > algorithms" - except that it tends to not be very performant. Depends on who's writing the Haskell in my experience. GHC's a perfectly capable compiler if you feed it the proper diet. -- Don (Board member of the "Don't think linked lists are the same as UArr Double" movement) From jeremy at n-heptane.com Wed Nov 12 17:17:54 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Wed Nov 12 17:03:24 2008 Subject: [Haskell-cafe] Turning all the Nothings into Just defaultValue using Data.Generics In-Reply-To: References: Message-ID: <87zlk4vbal.wl%jeremy@n-heptane.com> Hello, I can *almost* do it like this: test = (id `ext1T` justDefault) (defaultValue :: A) justDefault :: forall f. (Default f, Data f) => Maybe f -> Maybe f justDefault Nothing = defaultValue justDefault (Just x) = Just x Except it fails with: Could not deduce (Default d1) from the context (Data d1) arising from a use of `justDefault' at /tmp/type.hs:31:19-29 Possible fix: add (Default d1) to the context of the polymorphic type `forall d1. (Data d1) => t d1 -> t d1' In the second argument of `ext1T', namely `justDefault' In the expression: (id `ext1T` justDefault) (defaultValue :: A) In the definition of `test': test = (id `ext1T` justDefault) (defaultValue :: A) If we could figure out a way to write justDefault so that it did not require the Default class, then things would work. It would be nice if there was a way to do one thing if a value is an instance of Default and something else if it is not. Here is some psuedo-Haskell code showing what I mean: justDefault :: forall f. (Data f) => Maybe f -> Maybe f justDefault Nothing | (Default f) => defaultValue | _ => Nothing justDefault (Just x) = Just x Any ideas? j. At Wed, 12 Nov 2008 09:46:05 -0800, David Fox wrote: > > [1 ] > [1.1 ] > I want to use Data.Generics to write a function to turn all the Nothings in > a data structure into Just defaultValue, as shown below. I get the > following error because the compiler doesn't know enough about Maybe a for > mkT to create the generic function that everywhere requires, I guess. > > Test.hs:26:16: > Ambiguous type variable `a' in the constraints: > `Typeable a' > arising from a use of `mkT' at Senior/Test2.hs:26:16-30 > `Default a' > arising from a use of `justDefault' at Senior/Test2.hs:26:20-30 > Probable fix: add a type signature that fixes these type variable(s) > > Here is the example. It all works except for "test". Any suggestions how > to do this? > > {-# LANGUAGE DeriveDataTypeable, FlexibleContexts, FlexibleInstances, > MultiParamTypeClasses, RankNTypes, TemplateHaskell, TypeSynonymInstances #-} > {-# OPTIONS_GHC -fallow-undecidable-instances #-} > module Test where > > import Data.Generics > > class Default a where > defaultValue :: a > > instance Default Int where > defaultValue = 0 > > instance Default String where > defaultValue = "" > > instance Default (Maybe a) where > defaultValue = Nothing > > data A = A {b :: Int, c :: Maybe String} deriving (Show, Data, Typeable) > > instance Default A where > defaultValue = A {b = defaultValue, c = defaultValue} > > test = > everywhere (mkT justDefault) (defaultValue :: A) > where > justDefault Nothing = Just defaultValue > justDefault (Just x) = Just x > [1.2 ] > > [2 ] > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From malcolm.wallace at cs.york.ac.uk Wed Nov 12 17:11:06 2008 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Nov 12 17:08:35 2008 Subject: [Haskell-cafe] Re: What *not* to use Haskell for In-Reply-To: References: <1226399902.6496.9.camel@rubix.office.last.fm> Message-ID: >> "what does Haskell not do well?" > > - When you feed it Java code. Incidentally, the same holds when you > feed it C code. I've heard that Haskell's new (developed in this year's GSoC) Language.C libraries were able to parse millions of lines of C code from the Linux kernel, including many gcc extensions, without a single error. That doesn't sound too shabby to me. Regards, Malcolm From david.maciver at gmail.com Wed Nov 12 17:16:44 2008 From: david.maciver at gmail.com (David MacIver) Date: Wed Nov 12 17:11:10 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: References: <491AABE9.5070700@nobugs.org> <2f9b2d30811121047h10582d4bq332ab174487ada52@mail.gmail.com> Message-ID: On Wed, Nov 12, 2008 at 8:35 PM, Lennart Augustsson wrote: > Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. Really? It seems easy to create things with it which when passed to ostensibly pure functions yield different results depending on their evaluation order: module Main where import System.IO.Unsafe import Data.IORef main = do w1 <- weirdTuple print w1 w2 <- weirdTuple print $ swap w2 swap (x, y) = (y, x) weirdTuple :: IO (Int, Int) weirdTuple = do it <- newIORef 1 x <- unsafeInterleaveIO $ readIORef it y <- unsafeInterleaveIO $ do writeIORef it 2 >> return 1 return (x, y) david@mel:~$ ./Unsafe (1,1) (1,2) So show isn't acting in a referentially transparent way: If the second part of the tuple were evaluated before the first part it would give a different answer (as swapping demonstrates). From lists at qseep.net Wed Nov 12 17:29:22 2008 From: lists at qseep.net (Lyle Kopnicky) Date: Wed Nov 12 17:23:49 2008 Subject: [Haskell-cafe] TimeDiff to Int? In-Reply-To: References: <670e468e0811120810g26481a76tb1dddf274c11fa0f@mail.gmail.com> Message-ID: <670e468e0811121429t70420833y2f8f292caff1c663@mail.gmail.com> Thanks Philip and Roger, I think I'll use... floor $ toRational td ...although I could have sworn that didn't work last night. I don't see that TimeDiff has an instance of RealFrac, where floor is defined, though it does have a instances of Real and Fractional. Yes, the numeric classes are a bit hard to follow. Especially confusing is the conversions. I'm thinking of making a multiparameter Coercible class, with a coerce function, to help address that. - Lyle On Wed, Nov 12, 2008 at 9:43 AM, Philip Weaver wrote: > > > 2008/11/12 Lyle Kopnicky > > Hi folks, >> >> I had some code using the oldtime package, and want to convert it to use >> the time package. >> >> One of the things I need to do is calculate the number of seconds since >> midnight. The easy part is getting a TimeDiff result: >> >> utc <- getCurrentTime >> tz <- getCurrentTimeZone >> let td = timeOfDayToTime $ localTimeOfDay $ utcToLocalTime tz utc >> >> Now td is a TimeDiff representation of the number of seconds since >> midnight. It prints nicely, but I'm having a heck of a time figuring out how >> to truncate it to an Int. >> >> The floor function is only supported by the RealFrac class. Although >> TimeDiff has an instance of RealFrac and Fractional, it doesn't have an >> instance of RealFrac. I looked up the various to* and from* functions and >> have come up short. fromEnum yields an Int but it's the wrong value. I know >> I could use show and then use readS to get an Integer, or use formatTime >> (and reparse that), but that's a hack. >> >> I can convert it to a TimeOfDay which gives me hours, minutes, and >> seconds, but then I have to do arithmetic on it, and the seconds are of type >> Pico, which I can't call floor on either. I can convert it to a Rational via >> timeOfDayToDayFraction, but a TimeDiff is already a Rational those don't >> have floor. >> >> What am I missing? There has got to be an easy way to count seconds! >> > > Well, you could always (read . takeWhile (not . (=='.')) . show), but > here's a better way: > > let x = toRational td > in numerator x `div` denominator x > > This was just the first thing I could come up with. I bet there's a nicer > way. > > - Phil > > >> Thanks, >> Lyle >> >> >> _______________________________________________ >> 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/20081112/c571d0c2/attachment.htm From ales.bizjak0 at gmail.com Wed Nov 12 17:32:14 2008 From: ales.bizjak0 at gmail.com (=?utf-8?B?QWxlxaEgQml6amFr?=) Date: Wed Nov 12 17:26:44 2008 Subject: [Haskell-cafe] GHC 6.10, strange behaviour when profiling? In-Reply-To: <916b84820811110254q61b5211dl1d93fef26432c69a@mail.gmail.com> References: <916b84820811110254q61b5211dl1d93fef26432c69a@mail.gmail.com> Message-ID: Compiled with ghc-6.10.1.20081112 it runs approximately as it did with ghc-6.8.3 so the problem seems to be fixed. Thank you for your help. From jonathanccast at fastmail.fm Wed Nov 12 17:45:27 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Nov 12 17:40:03 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: References: <491AABE9.5070700@nobugs.org> <2f9b2d30811121047h10582d4bq332ab174487ada52@mail.gmail.com> Message-ID: <1226529927.26242.42.camel@jcchost> On Wed, 2008-11-12 at 22:16 +0000, David MacIver wrote: > On Wed, Nov 12, 2008 at 8:35 PM, Lennart Augustsson > wrote: > > Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. > > Really? It seems easy to create things with it which when passed to > ostensibly pure functions yield different results depending on their > evaluation order: > > module Main where > > import System.IO.Unsafe > import Data.IORef > > main = do w1 <- weirdTuple > print w1 > w2 <- weirdTuple > print $ swap w2 > > swap (x, y) = (y, x) > > weirdTuple :: IO (Int, Int) > weirdTuple = do it <- newIORef 1 > x <- unsafeInterleaveIO $ readIORef it > y <- unsafeInterleaveIO $ do writeIORef it 2 >> return 1 > return (x, y) > > david@mel:~$ ./Unsafe > (1,1) > (1,2) > > So show isn't acting in a referentially transparent way: If the second > part of the tuple were evaluated before the first part it would give a > different answer (as swapping demonstrates). It seems that this argument depends on being able to find a case where w1 and swap w1 actually behave differently. weirdTuple is non-deterministic, but that's fine, since it's in the IO monad. And w1 and w2 are simply two (distinct!) lambda-bound variables; there is no requirement that two different lambda-bound variables behave in the same fashion, regardless of how values may be expected to be supplied for them at run time (what values the functions in question may be expected to be applied to) unless the function(s) they are formal parameters of are (both) applied to the same expression. (>>=) certainly does not count as `application' for present purposes. Even if it is insisted (why? I don't think GHC actually guarantees to produce the above result when main is executed) that main must always yield the above result, it does not follow that unsafePerformIO is non-RT; it is still only non-causal. But referential transparency doesn't require that the result of an IO action must depend only on events that transpire by the time it finishes running; it places, in fact, no requirement on the run-time behavior of any IO action at all. It requires only that equal expressions be substitutable for equals; and, again, w1 and w2 being the result of calling a single IO action with no dependence on the outside world does not require them to be equal, under any system of semantics. So, no violation of RT. jcc From dons at galois.com Wed Nov 12 17:46:09 2008 From: dons at galois.com (Don Stewart) Date: Wed Nov 12 17:40:37 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: References: <491AABE9.5070700@nobugs.org> <2f9b2d30811121047h10582d4bq332ab174487ada52@mail.gmail.com> Message-ID: <20081112224609.GG1099@scytale.galois.com> david.maciver: > On Wed, Nov 12, 2008 at 8:35 PM, Lennart Augustsson > wrote: > > Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. > > Really? It seems easy to create things with it which when passed to > ostensibly pure functions yield different results depending on their > evaluation order: > > module Main where > > import System.IO.Unsafe > import Data.IORef > > main = do w1 <- weirdTuple > print w1 > w2 <- weirdTuple > print $ swap w2 > > swap (x, y) = (y, x) > > weirdTuple :: IO (Int, Int) > weirdTuple = do it <- newIORef 1 > x <- unsafeInterleaveIO $ readIORef it > y <- unsafeInterleaveIO $ do writeIORef it 2 >> return 1 > return (x, y) > > david@mel:~$ ./Unsafe > (1,1) > (1,2) > > So show isn't acting in a referentially transparent way: If the second > part of the tuple were evaluated before the first part it would give a > different answer (as swapping demonstrates). Mmmm? No. Where's the pure function that's now producing different results? I only see IO actions at play, which are operating on the state of the world. From david.maciver at gmail.com Wed Nov 12 18:02:17 2008 From: david.maciver at gmail.com (David MacIver) Date: Wed Nov 12 17:56:45 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: <20081112224609.GG1099@scytale.galois.com> References: <491AABE9.5070700@nobugs.org> <2f9b2d30811121047h10582d4bq332ab174487ada52@mail.gmail.com> <20081112224609.GG1099@scytale.galois.com> Message-ID: On Wed, Nov 12, 2008 at 10:46 PM, Don Stewart wrote: > david.maciver: >> On Wed, Nov 12, 2008 at 8:35 PM, Lennart Augustsson >> wrote: >> > Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. >> >> Really? It seems easy to create things with it which when passed to >> ostensibly pure functions yield different results depending on their >> evaluation order: >> >> module Main where >> >> import System.IO.Unsafe >> import Data.IORef >> >> main = do w1 <- weirdTuple >> print w1 >> w2 <- weirdTuple >> print $ swap w2 >> >> swap (x, y) = (y, x) >> >> weirdTuple :: IO (Int, Int) >> weirdTuple = do it <- newIORef 1 >> x <- unsafeInterleaveIO $ readIORef it >> y <- unsafeInterleaveIO $ do writeIORef it 2 >> return 1 >> return (x, y) >> >> david@mel:~$ ./Unsafe >> (1,1) >> (1,2) >> >> So show isn't acting in a referentially transparent way: If the second >> part of the tuple were evaluated before the first part it would give a >> different answer (as swapping demonstrates). > > Mmmm? No. Where's the pure function that's now producing different > results? I only see IO actions at play, which are operating on the > state of the world. I suppose so. The point is that you have a pure function (show) and the results of evaluating it totally depend on its evaluation order. But you're still in the IO monad at this point so I suppose it technically "doesn't count" because it's only observable as the result of IO. It's pretty suspect behaviour, but not actually a failure of referential transparency. From jonathanccast at fastmail.fm Wed Nov 12 18:05:16 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Nov 12 17:59:52 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: References: <491AABE9.5070700@nobugs.org> <2f9b2d30811121047h10582d4bq332ab174487ada52@mail.gmail.com> <20081112224609.GG1099@scytale.galois.com> Message-ID: <1226531116.26242.44.camel@jcchost> On Wed, 2008-11-12 at 23:02 +0000, David MacIver wrote: > On Wed, Nov 12, 2008 at 10:46 PM, Don Stewart wrote: > > david.maciver: > >> On Wed, Nov 12, 2008 at 8:35 PM, Lennart Augustsson > >> wrote: > >> > Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. > >> > >> Really? It seems easy to create things with it which when passed to > >> ostensibly pure functions yield different results depending on their > >> evaluation order: > >> > >> module Main where > >> > >> import System.IO.Unsafe > >> import Data.IORef > >> > >> main = do w1 <- weirdTuple > >> print w1 > >> w2 <- weirdTuple > >> print $ swap w2 > >> > >> swap (x, y) = (y, x) > >> > >> weirdTuple :: IO (Int, Int) > >> weirdTuple = do it <- newIORef 1 > >> x <- unsafeInterleaveIO $ readIORef it > >> y <- unsafeInterleaveIO $ do writeIORef it 2 >> return 1 > >> return (x, y) > >> > >> david@mel:~$ ./Unsafe > >> (1,1) > >> (1,2) > >> > >> So show isn't acting in a referentially transparent way: If the second > >> part of the tuple were evaluated before the first part it would give a > >> different answer (as swapping demonstrates). > > > > Mmmm? No. Where's the pure function that's now producing different > > results? I only see IO actions at play, which are operating on the > > state of the world. > > I suppose so. The point is that you have a pure function (show) and > the results of evaluating it totally depend on its evaluation order. Sure. But only because the argument to it depends on its evaluation order, as well. jcc From david.maciver at gmail.com Wed Nov 12 18:18:38 2008 From: david.maciver at gmail.com (David MacIver) Date: Wed Nov 12 18:13:06 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: <1226531116.26242.44.camel@jcchost> References: <491AABE9.5070700@nobugs.org> <2f9b2d30811121047h10582d4bq332ab174487ada52@mail.gmail.com> <20081112224609.GG1099@scytale.galois.com> <1226531116.26242.44.camel@jcchost> Message-ID: On Wed, Nov 12, 2008 at 11:05 PM, Jonathan Cast wrote: > On Wed, 2008-11-12 at 23:02 +0000, David MacIver wrote: >> On Wed, Nov 12, 2008 at 10:46 PM, Don Stewart wrote: >> > david.maciver: >> >> On Wed, Nov 12, 2008 at 8:35 PM, Lennart Augustsson >> >> wrote: >> >> > Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. >> >> >> >> Really? It seems easy to create things with it which when passed to >> >> ostensibly pure functions yield different results depending on their >> >> evaluation order: >> >> >> >> module Main where >> >> >> >> import System.IO.Unsafe >> >> import Data.IORef >> >> >> >> main = do w1 <- weirdTuple >> >> print w1 >> >> w2 <- weirdTuple >> >> print $ swap w2 >> >> >> >> swap (x, y) = (y, x) >> >> >> >> weirdTuple :: IO (Int, Int) >> >> weirdTuple = do it <- newIORef 1 >> >> x <- unsafeInterleaveIO $ readIORef it >> >> y <- unsafeInterleaveIO $ do writeIORef it 2 >> return 1 >> >> return (x, y) >> >> >> >> david@mel:~$ ./Unsafe >> >> (1,1) >> >> (1,2) >> >> >> >> So show isn't acting in a referentially transparent way: If the second >> >> part of the tuple were evaluated before the first part it would give a >> >> different answer (as swapping demonstrates). >> > >> > Mmmm? No. Where's the pure function that's now producing different >> > results? I only see IO actions at play, which are operating on the >> > state of the world. >> >> I suppose so. The point is that you have a pure function (show) and >> the results of evaluating it totally depend on its evaluation order. > > Sure. But only because the argument to it depends on its evaluation > order, as well. That's not really better. :-) To put it a different way, in the absence of unsafeInterleaveIO the IO monad has the property that if f and g are observably equal up to termination then x >>= f and x >>= g are equivalent in the IO monad (actually this may not be true due to exception handling. Our three main weapons...). In the presence of unsafeInterleaveIO this property is lost even though referential transparency is retained. Anyway, I'll shut up now. From mdmkolbe at gmail.com Wed Nov 12 18:23:00 2008 From: mdmkolbe at gmail.com (Michael D. Adams) Date: Wed Nov 12 18:17:31 2008 Subject: [Haskell-cafe] ANNOUNCE: hpapi 0.1 release Message-ID: I am pleased to announce the first release of hpapi, Performance API (PAPI) bindings for Haskell. The release is on Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hpapi The source repository is at: http://code.haskell.org/hpapi/ Please send bug reports to What is it ========== This is a simple set of bindings for the Performance API (PAPI). PAPI provides access to various CPU counters such as cache-miss, instruction and pipeline stall counts. The easiest way to use this library is the withCounts function: withCounts :: [EventCode] -> IO a -> IO (a, [Integer]) Given a list of events to count and an IO operation it will run the operation and return the resulting counts. So you could do something like: main = do [l1,tlb,fp] <- withCounters [papi_l1_dcm, papi_tlb_dm, papi_fp_ins] ioOperationToMeasure printLn (l1, tlb, fp) To use it one will of course need the PAPI C library and any necessary kernel modifications installed. Status ====== The High Level interface (which will be sufficient for most people's needs) should be usable, but the low level interface is still alpha quality. That is to say, it is ready for people to start banging on it, but it is largely untested and the modules/interfaces may be reorganized based on user feedback. All of PAPI is supported with the exception of the following "advanced" features: - Multiplexing - Threads - Locks - Overflow - Statistical Profiling Future Directions ================= Future directions will be determined largely by user feedback. Principal areas that I am looking for feedback on are: - documentation - module organization - the handling of PAPI errors (currently it throws an IO error) - the design of the Haskell interface build on top of the C level PAPI_get_opt and PAPI_set_opt - what advanced features of PAPI to build bindings for next Comparison with GHC's built-in PAPI =================================== GHC supports a built-in version of PAPI (see http://hackage.haskell.org/trac/ghc/wiki/PAPI). This system is different in a few ways. First, hpapi allows you to measure specific parts of a program while GHCI's PAPI only does whole program measurement Second, since hpapi is a library you can have fine grained and sophisticated control over how things are measured. On the other hand GHC's PAPI as part of the RTS gives you less control, but on the plus side doesn't require any modification to the program. Finally, GHC's PAPI splits apart the counts that come from the garbage collector from those that come from the mutator, while hpapi combines them. This is a limitation of hpapi we hope to correct some time in the future. It remains to be seen whether it would be worth while to unify these two systems. ================ Bug reports as well as suggestions, feedback or contributions to the API or the documentation most welcome. Michael D. Adams From jonathanccast at fastmail.fm Wed Nov 12 18:24:20 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Nov 12 18:18:55 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: References: <491AABE9.5070700@nobugs.org> <2f9b2d30811121047h10582d4bq332ab174487ada52@mail.gmail.com> <20081112224609.GG1099@scytale.galois.com> <1226531116.26242.44.camel@jcchost> Message-ID: <1226532260.26242.46.camel@jcchost> On Wed, 2008-11-12 at 23:18 +0000, David MacIver wrote: > On Wed, Nov 12, 2008 at 11:05 PM, Jonathan Cast > wrote: > > On Wed, 2008-11-12 at 23:02 +0000, David MacIver wrote: > >> On Wed, Nov 12, 2008 at 10:46 PM, Don Stewart wrote: > >> > david.maciver: > >> >> On Wed, Nov 12, 2008 at 8:35 PM, Lennart Augustsson > >> >> wrote: > >> >> > Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. > >> >> > >> >> Really? It seems easy to create things with it which when passed to > >> >> ostensibly pure functions yield different results depending on their > >> >> evaluation order: > >> >> > >> >> module Main where > >> >> > >> >> import System.IO.Unsafe > >> >> import Data.IORef > >> >> > >> >> main = do w1 <- weirdTuple > >> >> print w1 > >> >> w2 <- weirdTuple > >> >> print $ swap w2 > >> >> > >> >> swap (x, y) = (y, x) > >> >> > >> >> weirdTuple :: IO (Int, Int) > >> >> weirdTuple = do it <- newIORef 1 > >> >> x <- unsafeInterleaveIO $ readIORef it > >> >> y <- unsafeInterleaveIO $ do writeIORef it 2 >> return 1 > >> >> return (x, y) > >> >> > >> >> david@mel:~$ ./Unsafe > >> >> (1,1) > >> >> (1,2) > >> >> > >> >> So show isn't acting in a referentially transparent way: If the second > >> >> part of the tuple were evaluated before the first part it would give a > >> >> different answer (as swapping demonstrates). > >> > > >> > Mmmm? No. Where's the pure function that's now producing different > >> > results? I only see IO actions at play, which are operating on the > >> > state of the world. > >> > >> I suppose so. The point is that you have a pure function (show) and > >> the results of evaluating it totally depend on its evaluation order. > > > > Sure. But only because the argument to it depends on its evaluation > > order, as well. > > That's not really better. :-) I never said it was. jcc From derek.a.elkins at gmail.com Wed Nov 12 18:35:28 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Wed Nov 12 18:30:04 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: References: <491AABE9.5070700@nobugs.org> <2f9b2d30811121047h10582d4bq332ab174487ada52@mail.gmail.com> <20081112224609.GG1099@scytale.galois.com> Message-ID: <1226532928.15731.17.camel@derek-laptop> On Wed, 2008-11-12 at 23:02 +0000, David MacIver wrote: > On Wed, Nov 12, 2008 at 10:46 PM, Don Stewart wrote: > > david.maciver: > >> On Wed, Nov 12, 2008 at 8:35 PM, Lennart Augustsson > >> wrote: > >> > Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. > >> > >> Really? It seems easy to create things with it which when passed to > >> ostensibly pure functions yield different results depending on their > >> evaluation order: > >> > >> module Main where > >> > >> import System.IO.Unsafe > >> import Data.IORef > >> > >> main = do w1 <- weirdTuple > >> print w1 > >> w2 <- weirdTuple > >> print $ swap w2 > >> > >> swap (x, y) = (y, x) > >> > >> weirdTuple :: IO (Int, Int) > >> weirdTuple = do it <- newIORef 1 > >> x <- unsafeInterleaveIO $ readIORef it > >> y <- unsafeInterleaveIO $ do writeIORef it 2 >> return 1 > >> return (x, y) > >> > >> david@mel:~$ ./Unsafe > >> (1,1) > >> (1,2) > >> > >> So show isn't acting in a referentially transparent way: If the second > >> part of the tuple were evaluated before the first part it would give a > >> different answer (as swapping demonstrates). > > > > Mmmm? No. Where's the pure function that's now producing different > > results? I only see IO actions at play, which are operating on the > > state of the world. > > I suppose so. The point is that you have a pure function (show) and > the results of evaluating it totally depend on its evaluation order. > But you're still in the IO monad at this point so I suppose it > technically "doesn't count" because it's only observable as the result > of IO. > > It's pretty suspect behaviour, but not actually a failure of > referential transparency. Indeed. There's a difference between purity and referential transparency. A lack of purity is when behaviour, as in semantics, depends on evaluation order (modulo bottom of course). Referential transparency is being able to substitute equals for equals. These notions are related but independent. Examples of failures of referential transparency that aren't failures of purity are easy to find. A simple one would be some kind of introspection feature, such as various forms of quotation, being able to ask for the name of a variable, being able to serialize functions. So purity doesn't imply referential transparency. Failures of purity that aren't failures of referential transparency are a bit trickier since without purity (i.e. evaluation order independence) what constitutes a valid substitution may vary. Still, as an easy start, a language with no binding forms is trivially referentially transparent regardless of how impure it may be. If you use a call-by-name evaluation order, the full beta rule holds and evaluation proceeds by substituting equals for equals and therefore such a language is also referentially transparent. So referential transparency doesn't imply purity. From dan.doel at gmail.com Wed Nov 12 18:47:00 2008 From: dan.doel at gmail.com (Dan Doel) Date: Wed Nov 12 18:41:32 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: References: <491AABE9.5070700@nobugs.org> <1226531116.26242.44.camel@jcchost> Message-ID: <200811121847.00966.dan.doel@gmail.com> On Wednesday 12 November 2008 6:18:38 pm David MacIver wrote: > To put it a different way, in the absence of unsafeInterleaveIO the IO > monad has the property that if f and g are observably equal up to > termination then x >>= f and x >>= g are equivalent in the IO monad > (actually this may not be true due to exception handling. Our three > main weapons...). In the presence of unsafeInterleaveIO this property > is lost even though referential transparency is retained. I'm not sure what exactly you mean by this, but, for instance: randomIO >>= (print :: Int -> IO ()) obviously isn't going to give the same results as: randomIO >>= (print :: Int -> IO ()) every time. Your weirdTuple is semantically similar, in that it selects between returning (1,1) and (2,1), but instead of being random, it operationally selects depending on how you subsequently evaluate the value. That may not seem like the same thing, because you know what's going on, but formally, I imagine you can treat it all as a black box where either "this time it gave (2,1)" or "this time it gave (1,1)", and what you see is always consistent. The fact that it sort of uses an oracle to see what will happen in its future is just The Power of IO (it does have a sort of "spooky action" feel to it). :) -- Dan From jonathanccast at fastmail.fm Wed Nov 12 19:05:02 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Nov 12 18:59:36 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: <200811121847.00966.dan.doel@gmail.com> References: <491AABE9.5070700@nobugs.org> <1226531116.26242.44.camel@jcchost> <200811121847.00966.dan.doel@gmail.com> Message-ID: <1226534702.26242.50.camel@jcchost> On Wed, 2008-11-12 at 18:47 -0500, Dan Doel wrote: > On Wednesday 12 November 2008 6:18:38 pm David MacIver wrote: > > To put it a different way, in the absence of unsafeInterleaveIO the IO > > monad has the property that if f and g are observably equal up to > > termination then x >>= f and x >>= g are equivalent in the IO monad > > (actually this may not be true due to exception handling. Our three > > main weapons...). In the presence of unsafeInterleaveIO this property > > is lost even though referential transparency is retained. > > I'm not sure what exactly you mean by this, but, for instance: > > randomIO >>= (print :: Int -> IO ()) > > obviously isn't going to give the same results as: > > randomIO >>= (print :: Int -> IO ()) > > every time. Your weirdTuple is semantically similar, in that it selects > between returning (1,1) and (2,1), but instead of being random, it > operationally selects depending on how you subsequently evaluate the value. I think the point is that randomIO is non-deterministic (technically, pseudo-random) but causal --- the result is completely determined by events that precede its completion. unsafeInterleaveIO, by contrast, is arguably (sometimes) deterministic --- but is, regardless, definitely not causal. jcc From lennart at augustsson.net Wed Nov 12 19:14:57 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Nov 12 19:09:24 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: <1226534702.26242.50.camel@jcchost> References: <491AABE9.5070700@nobugs.org> <1226531116.26242.44.camel@jcchost> <200811121847.00966.dan.doel@gmail.com> <1226534702.26242.50.camel@jcchost> Message-ID: But how can you tell something being causal or not? Assuming that all IO operations return random result, of course. :) >From a practical point of view unsafeInterleaveIO can give suspect results. But theoretically you can't fault it until you have given a semantics for the IO monad operations so you have something to compare it against. -- Lennart On Thu, Nov 13, 2008 at 12:05 AM, Jonathan Cast wrote: > On Wed, 2008-11-12 at 18:47 -0500, Dan Doel wrote: >> On Wednesday 12 November 2008 6:18:38 pm David MacIver wrote: >> > To put it a different way, in the absence of unsafeInterleaveIO the IO >> > monad has the property that if f and g are observably equal up to >> > termination then x >>= f and x >>= g are equivalent in the IO monad >> > (actually this may not be true due to exception handling. Our three >> > main weapons...). In the presence of unsafeInterleaveIO this property >> > is lost even though referential transparency is retained. >> >> I'm not sure what exactly you mean by this, but, for instance: >> >> randomIO >>= (print :: Int -> IO ()) >> >> obviously isn't going to give the same results as: >> >> randomIO >>= (print :: Int -> IO ()) >> >> every time. Your weirdTuple is semantically similar, in that it selects >> between returning (1,1) and (2,1), but instead of being random, it >> operationally selects depending on how you subsequently evaluate the value. > > I think the point is that randomIO is non-deterministic (technically, > pseudo-random) but causal --- the result is completely determined by > events that precede its completion. unsafeInterleaveIO, by contrast, is > arguably (sometimes) deterministic --- but is, regardless, definitely > not causal. > > jcc > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From trin.cz at gmail.com Wed Nov 12 19:20:21 2008 From: trin.cz at gmail.com (Trin) Date: Wed Nov 12 19:14:51 2008 Subject: [Haskell-cafe] HOpenGL shading problem Message-ID: <491B72C5.4010705@gmail.com> Hi, last few days I spent making remake of glxgears. Nothing fancy, I just wanted easily configurable gears. The current performance is only about 70% of glxgears. But I have a problem with shading. Whatever I have been trying, I still don't understand how the shading can be activated. I have light, I have color, but not even Flat shading. Please can you give me a hand? Thanks, Martin PS: I didn't find any attachment size policy for this list, so I hope that the attachment is small enough. -------------- next part -------------- A non-text attachment was scrubbed... Name: Gear.hs Type: text/x-haskell Size: 8124 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081113/ee4b72fa/Gear.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: testGear2.hs Type: text/x-haskell Size: 4924 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081113/ee4b72fa/testGear2.bin From ajb at spamcop.net Wed Nov 12 19:40:58 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed Nov 12 19:35:32 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <594c1e830811121401m6624654h4c03dd50abf671b1@mail.gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <491969F4.6000300@jellybean.co.uk> <594c1e830811121401m6624654h4c03dd50abf671b1@mail.gmail.com> Message-ID: <20081112194058.zl9dncky884cks08-nwo@webmail.spamcop.net> G'day all. Quoting Tom Hawkins : > Actually, Haskell is an excellent language for hard real-time > applications. At Eaton we're using it for automotive powertrain > control. Of course, the RTS is not running in the loop. Instead, we > write in a DSL, which generates C code for our vehicle ECU. Bingo! And thanks for someone for admitting that they do this. :-) "Hard real-time applications" is a huge area, and not all of the code that you write is code that ends up running on the target. Generally, in DSL/MDD-style development, not very much of the code that you write ends up running on the target. In some cases, _none_ of the code you write ends up running on the target. Haskell is almost ideal for tasks like this. Cheers, Andrew Bromage From garious at gmail.com Wed Nov 12 19:52:06 2008 From: garious at gmail.com (Greg Fitzgerald) Date: Wed Nov 12 19:46:32 2008 Subject: [Haskell-cafe] Linker errors to OpenGL with GHC 6.10.1 Message-ID: <1f3dc80d0811121652y1b9eec2bve512e274bf04055c@mail.gmail.com> Do you know how I can fix these linker errors? C:\projects\fun>cat HelloWorld.hs import Graphics.Rendering.OpenGL import Graphics.UI.GLUT main = do (progname, _) <- getArgsAndInitialize createWindow "Hello World" displayCallback $= clear [ColorBuffer] mainLoop C:\projects\fun>ls lib GlU32.Lib glut32.lib OpenGL32.Lib glut.def glut32.dll C:\projects\fun>ghc -Llib -lglut32 -lglu32 -lopengl32 HelloWorld.hs --make Linking HelloWorld.exe ... C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.10.1/libHSGLUT-2.1.1.2.a(Begin.o):fake:(.text+0x1cb): undefined reference to `glutGet' C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.10.1/libHSGLUT-2.1.1.2.a(Begin.o):fake:(.text+0x8af): undefined reference to `glutMainLoop' C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.10.1/libHSGLUT-2.1.1.2.a(Window.o):fake:(.text+0x3cd): undefined reference to `glutEntryFunc' C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.10.1/libHSGLUT-2.1.1.2.a(Window.o):fake:(.text+0x40d): undefined reference to `glutVisibilityFunc' C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.10.1/libHSGLUT-2.1.1.2.a(Window.o):fake:(.text+0x3595): undefined reference to `glutPassiveMotionFunc' ...hundreds more... Thanks, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081112/2bf3bb5a/attachment.htm From ryani.spam at gmail.com Wed Nov 12 21:21:41 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Nov 12 21:16:07 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: <491B5260.4030903@nobugs.org> References: <491AABE9.5070700@nobugs.org> <491B5260.4030903@nobugs.org> Message-ID: <2f9b2d30811121821h51ce2ce3tcacae0aab951d6de@mail.gmail.com> Interesting posts. Thanks! On Wed, Nov 12, 2008 at 2:02 PM, Andrew Birkett wrote: > Thanks for the reference, and also to everyone who replied - all very > useful and interesting. For what it's worth, the blog posts I was writing > are here: > > http://www.nobugs.org/blog/archives/2008/11/12/why-do-they-call-it-referentially-transparent/ > http://www.nobugs.org/blog/archives/2008/11/12/why-do-they-call-it-referentially-transparent-ii/ From p3k at iki.fi Thu Nov 13 02:18:21 2008 From: p3k at iki.fi (Pekka Karjalainen) Date: Thu Nov 13 02:12:48 2008 Subject: [Haskell-cafe] Linker errors to OpenGL with GHC 6.10.1 In-Reply-To: <1f3dc80d0811121652y1b9eec2bve512e274bf04055c@mail.gmail.com> References: <1f3dc80d0811121652y1b9eec2bve512e274bf04055c@mail.gmail.com> Message-ID: <233457100811122318u5d9654cco5b8445cfddddf1d9@mail.gmail.com> 2008/11/13 Greg Fitzgerald : > Do you know how I can fix these linker errors? > > C:\projects\fun>cat HelloWorld.hs > > import Graphics.Rendering.OpenGL > import Graphics.UI.GLUT > main = do > (progname, _) <- getArgsAndInitialize > createWindow "Hello World" > displayCallback $= clear [ColorBuffer] > mainLoop > > C:\projects\fun>ls lib > GlU32.Lib > glut32.lib > OpenGL32.Lib > glut.def > glut32.dll > > C:\projects\fun>ghc -Llib -lglut32 -lglu32 -lopengl32 HelloWorld.hs --make > Linking HelloWorld.exe ... > C:\Program > Files\Haskell\GLUT-2.1.1.2\ghc-6.10.1/libHSGLUT-2.1.1.2.a(Begin.o):fake:(.text+0x1cb): > undefined reference to `glutGet' [...] > Thanks, > Greg I'm assuming this is on Windows because of C:\... These kinds of linker errors happened to me when I built libHSGLUT with a wrong type of calling convention (by accident). There are two callconvs, and they are called stdcall and ccall on the Haskell side. The 'runhaskell setup configure' step is supposed to detect the correct one to use, so you should run it and then grep for lines with CALLCONV. They should say stdcall on Windows. If you find them saying ccall, that's likely the cause of all the linker errors. (Most Windows dynamic libraries use stdcall, but for extra configuration fun OpenAL uses ccall.) If this is the problem, you can change the offending ccall in the configuration files to stdcall and rebuild the library. Grepping for CALLCONV will also show the places you need to change this way. In my case the wrong configuration came from using the sh program from Cygwin. With the MSYS variety there was no problem. To be exact, it came down to the $host variable checked by the configuration script. Pekka From lists at qseep.net Thu Nov 13 02:43:09 2008 From: lists at qseep.net (Lyle Kopnicky) Date: Thu Nov 13 02:37:34 2008 Subject: [Haskell-cafe] getLine and ^C on Windows Message-ID: <670e468e0811122343p7531e32ub8618f127f57b42e@mail.gmail.com> Hi folks, I'm using System.IO.getLine to read input in my program. I've compiled it on Windows Vista with ghc-6.10.1. I've noticed that if I press Ctrl+C while the program is waiting for input, it will get stuck. No keypresses can get me out of the program - I have to kill the shell. I've tried cmd.exe, Powershell and cygwin - same behavior. I'm sure editline would work better, but it's overkill. I just want to read lines of text and don't need fancy edit behavior. And I think editline complicates the build process. I also want my program to work right in non-interactive mode, reading redirected input. Am I missing something? Thanks, Lyle -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081112/8dbb549f/attachment.htm From jgmorris at cecs.pdx.edu Thu Nov 13 04:23:58 2008 From: jgmorris at cecs.pdx.edu (J. Garrett Morris) Date: Thu Nov 13 04:18:24 2008 Subject: [Haskell-cafe] getLine and ^C on Windows In-Reply-To: <670e468e0811122343p7531e32ub8618f127f57b42e@mail.gmail.com> References: <670e468e0811122343p7531e32ub8618f127f57b42e@mail.gmail.com> Message-ID: <6cf91caa0811130123t2d9084cma01c20e87a536e57@mail.gmail.com> I've had the same experience with runghc in GHC 6.10.1 on Vista. /g 2008/11/12 Lyle Kopnicky : > Hi folks, > I'm using System.IO.getLine to read input in my program. I've compiled it on > Windows Vista with ghc-6.10.1. I've noticed that if I press Ctrl+C while the > program is waiting for input, it will get stuck. No keypresses can get me > out of the program - I have to kill the shell. I've tried cmd.exe, > Powershell and cygwin - same behavior. > I'm sure editline would work better, but it's overkill. I just want to read > lines of text and don't need fancy edit behavior. And I think editline > complicates the build process. I also want my program to work right in > non-interactive mode, reading redirected input. > Am I missing something? > Thanks, > Lyle > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- I am in here From neil.mitchell.2 at credit-suisse.com Thu Nov 13 04:34:56 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Thu Nov 13 04:30:18 2008 Subject: [Haskell-cafe] getLine and ^C on Windows In-Reply-To: <6cf91caa0811130123t2d9084cma01c20e87a536e57@mail.gmail.com> References: <670e468e0811122343p7531e32ub8618f127f57b42e@mail.gmail.com> <6cf91caa0811130123t2d9084cma01c20e87a536e57@mail.gmail.com> Message-ID: Hi I have the same experience with Windows XP and getContents, so I think it's the entire IO layer on Windows, rather than just getLine on Vista. This is being tracked here http://hackage.haskell.org/trac/ghc/ticket/2758 Thanks Neil > I've had the same experience with runghc in GHC 6.10.1 on Vista. > > /g > > 2008/11/12 Lyle Kopnicky : > > Hi folks, > > I'm using System.IO.getLine to read input in my program. > I've compiled > > it on Windows Vista with ghc-6.10.1. I've noticed that if I press > > Ctrl+C while the program is waiting for input, it will get > stuck. No > > keypresses can get me out of the program - I have to kill > the shell. > > I've tried cmd.exe, Powershell and cygwin - same behavior. > > I'm sure editline would work better, but it's overkill. I > just want to > > read lines of text and don't need fancy edit behavior. And I think > > editline complicates the build process. I also want my > program to work > > right in non-interactive mode, reading redirected input. > > Am I missing something? > > Thanks, > > Lyle > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > > -- > I am in here > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From tobias.bexelius at avalanchestudios.se Thu Nov 13 05:09:44 2008 From: tobias.bexelius at avalanchestudios.se (Tobias Bexelius) Date: Thu Nov 13 05:04:13 2008 Subject: [Haskell-cafe] Getting rid of functional dependencies with type proxies Message-ID: <698E8783CC407F4EB0DC9E994B6D4540D4B4AE@nut.avalanchestudios.se> Hi, some time ago I asked about a problem I had with functional dependencies conflicting when using overlapping instances in a code like this: {-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances -fallow-incoherent-instances #-} data V2 a = V2 a a class Vec v a where dot :: v a -> v a -> a instance Num a => Vec V2 a where V2 a1 a2 `dot` V2 b1 b2 = a1*b1+a2*b2 class Mult a b c | a b -> c where (*.) :: a -> b -> c instance (Num x) => Mult x x x where (*.) = (*) instance (Vec a x) => Mult (a x) (a x) x where (*.) = dot {- Functional dependencies conflict between instance declarations: instance [overlap ok] (Num x) => Mult x x x instance [overlap ok] (Vec a x) => Mult (a x) (a x) x -} The problem here is that the dependency check is occuring too soon. Removing the dependency would solve the problem, but then you would need to put type annotations everywhere you use the multiplication operator, and that's not acceptable. However, I did found a solution I would like to share with you: Creating a "type proxy"! I find it strange that such a simple solution to such a (for me at least) common problem hasn't been documented more. This is the working code: {-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances -fallow-incoherent-instances #-} data V2 a = V2 a a class Vec v a where dot :: v a -> v a -> a instance Num a => Vec V2 a where V2 a1 a2 `dot` V2 b1 b2 = a1*b1+a2*b2 class Mult a b c | a b -> c where (*.) :: a -> b -> c class MultProxy a b c where (*..) :: a -> b -> c instance MultProxy a b c => Mult a b c where (*.) = (*..) instance (Num x) => MultProxy x x x where (*..) = (*) instance (Vec a x) => MultProxy (a x) (a x) x where (*..) = dot Thanks to Emil Axelsson that pointed me to http://haskell.org/haskellwiki/GHC/AdvancedOverlap, where similar problems where discussed. Again, I haven't found links to this page in any of the Haskell tutorials I've read so far. /Tobias From jon.fairbairn at cl.cam.ac.uk Thu Nov 13 05:29:28 2008 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu Nov 13 05:24:08 2008 Subject: [Haskell-cafe] Re: TimeDiff to Int? References: <670e468e0811120810g26481a76tb1dddf274c11fa0f@mail.gmail.com> Message-ID: "Lyle Kopnicky" writes: > I had some code using the oldtime package, and want to convert it to use > the time package. > One of the things I need to do is calculate the number of seconds since > midnight. The easy part is getting a TimeDiff result: You mean DiffTime? > utc <- getCurrentTime > tz <- getCurrentTimeZone > let td = timeOfDayToTime $ localTimeOfDay $ utcToLocalTime tz utc > Now td is a TimeDiff representation of the number of seconds since > midnight. It prints nicely, but I'm having a heck of a time figuring out > how to truncate it to an Int. You could do something like fromEnum td `div` fromEnum (secondsToDiffTime 1) which says that you are computing a whole number of seconds. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2008-04-26) From mrchebas at gmail.com Thu Nov 13 05:37:17 2008 From: mrchebas at gmail.com (Alexey Rodriguez) Date: Thu Nov 13 05:31:41 2008 Subject: [Haskell-cafe] Turning all the Nothings into Just defaultValue using Data.Generics In-Reply-To: References: Message-ID: <4b39c80a0811130237k5b5accfbrbefdd6f176307b88@mail.gmail.com> Hi David! 2008/11/12 David Fox : > I want to use Data.Generics to write a function to turn all the Nothings in > a data structure into Just defaultValue, as shown below. I get the > following error because the compiler doesn't know enough about Maybe a for > mkT to create the generic function that everywhere requires, I guess. > > Test.hs:26:16: > Ambiguous type variable `a' in the constraints: > `Typeable a' > arising from a use of `mkT' at Senior/Test2.hs:26:16-30 > `Default a' > arising from a use of `justDefault' at Senior/Test2.hs:26:20-30 > Probable fix: add a type signature that fixes these type variable(s) > > Here is the example. It all works except for "test". Any suggestions how > to do this? The mkT function is used to turn a *monomorphic* transformation into a polymorphic one. Because justDefault is polymorphic and because mkT does not fix the type of justDefault, the constraints of justDefault won't be resolved. So you may need to fix the type of justDefault. How to solve this? You could give up your type class design and write the type specific cases of justDefault using "extT". If you really want to use your type class design and hence keep "test" open to new Default instances, then SYB is most likely the wrong library for you. You could on the other hand use Scrap Your Boilerplate with class, which you can download from hackage[1]. This library was designed so that generic functions can be extended with additional type cases even after they have been defined. This fits your situation since you can give new default values using a type class. Using this library, your example looks like this: > import Data.Generics.SYB.WithClass.Basics > import Data.Generics.SYB.WithClass.Derive > import Data.Generics.SYB.WithClass.Instances > import Language.Haskell.TH() > > class Default a where > defaultValue :: a > > instance Default Int where > defaultValue = 0 > > instance Default String where > defaultValue = "" > > instance Default (Maybe a) where > defaultValue = Nothing > > data AB = AB {b :: Int, c :: Maybe String} deriving (Show) > > -- Derive data instances > $(derive [''AB]) > > instance Default AB where > defaultValue = AB {b = defaultValue, c = defaultValue} > > -- Dictionary and proxy for the justDefault function > data JustDefaultD a = JustDefaultD { justDefaultD :: a -> a } > justDefaultCtx :: Proxy JustDefaultD > justDefaultCtx = undefined > > -- Default case for justDefault (non Maybe type) > instance Sat (JustDefaultD a) where > dict = JustDefaultD id > > -- Maybe case for justDefault > instance Default a => Sat (JustDefaultD (Maybe a)) where > dict = JustDefaultD justDefault > where > justDefault Nothing = Just defaultValue > justDefault (Just x) = Just x > > test = everywhere justDefaultCtx (justDefaultD dict) (defaultValue :: AB) You will need the everywhere traversal which is not shipped in the package. You can download it from gp-bench[2]. Cheers, Alexey [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/syb-with-class [2] http://darcs.haskell.org/generics/comparison/syb3/Traversals.lhs From thomas at cs.ru.nl Thu Nov 13 05:39:17 2008 From: thomas at cs.ru.nl (Thomas van Noort) Date: Thu Nov 13 05:33:43 2008 Subject: [Haskell-cafe] ANNOUNCE: rewriting-0.1 In-Reply-To: <5de3f5ca0811081431m1513d463ye66df87c030d3d4@mail.gmail.com> References: <5de3f5ca0811081431m1513d463ye66df87c030d3d4@mail.gmail.com> Message-ID: <491C03D5.60700@cs.ru.nl> Hi Greg, We didn't look into nominal rewriting I'm afraid. And I'm not that familiar with scrap-your-nameplate so I'm not sure if you can implement nominal rewriting using that library. Regards, Thomas Greg Meredith wrote: > Thomas, > > Did you explore nominal rewrite at all? Do you know if it might be > possible to use the scrap-your-nameplate package to implement some > useful subset of the nominal rewrite machinery? > > 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 From Malcolm.Wallace at cs.york.ac.uk Thu Nov 13 06:26:35 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Nov 13 06:23:41 2008 Subject: [Haskell-cafe] HOpenGL shading problem In-Reply-To: <491B72C5.4010705@gmail.com> References: <491B72C5.4010705@gmail.com> Message-ID: <20081113112635.2c041b74.Malcolm.Wallace@cs.york.ac.uk> Trin wrote: > But I have a problem with shading. Whatever I have been trying, > I still don't understand how the shading can be activated. I have > light, I have color, but not even Flat shading. I think if you want shading, you need to compute the normals to each surface. Regards, Malcolm From dan.doel at gmail.com Thu Nov 13 07:14:44 2008 From: dan.doel at gmail.com (Dan Doel) Date: Thu Nov 13 07:09:18 2008 Subject: [Haskell-cafe] Proof that Haskell is RT In-Reply-To: <1226534702.26242.50.camel@jcchost> References: <491AABE9.5070700@nobugs.org> <200811121847.00966.dan.doel@gmail.com> <1226534702.26242.50.camel@jcchost> Message-ID: <200811130714.46161.dan.doel@gmail.com> On Wednesday 12 November 2008 7:05:02 pm Jonathan Cast wrote: > I think the point is that randomIO is non-deterministic (technically, > pseudo-random) but causal --- the result is completely determined by > events that precede its completion. unsafeInterleaveIO, by contrast, is > arguably (sometimes) deterministic --- but is, regardless, definitely > not causal. Sure, it's weird if you actually know how it's allegedly making its decisions (predicting the future, but not really). But all you can actually observe is that sometimes it gives (1,1), and sometimes it gives (2,1), and maybe it coincidentally always seems to give (1,1) to f, but to g, which is observationally equal to g, excepting bottoms, it always seems to give (2,1). That's a weird situation, but if you make things opaque enough, I think you can fall back on IO's nondeterminism. Another weird situation (it seems to me) goes like: foo = unsafeInterleaveIO $ fail "foo" do x <- foo putStrLn "bar" return $! x where you can't simply fall back to saying, "foo throws an exception," because it doesn't prevent "bar" from printing. So what is actually throwing an exception is some later IO action that doesn't have any relation to foo besides using a 'pure' result from it. However, I suppose you can push off such oddities in a similar way, saying that IO actions can throw delayed, asynchronous exceptions, and what do you know, it always happens to end up in the action that evaluated x. :) Of course, those sorts of explanations might be good enough to conclude that unsafeInterleaveIO doesn't break referential transparency, but they may make for a very poor operational semantics of IO and such. foo throws some delayed asynchronous exception? Well, that doesn't tell when or how. And it doesn't explain how weirdTuple 'nondeterministically' chooses between (1,1) and (2,1). So that would probably lead you to another semantics (a more operational one) that brings up how weirdTuple reads the future, or even that mutation happens as a result of evaluating pure values. But, the point is, I think, that such a semantics doesn't indicate that referential transparency is being violated (which would be a notion from another sort of semantics where there's no way to notice something weird is going on). Anyhow, I'm done rambling. (Hope it didn't go on too long; I know we weren't fundamentally in any kind of disagreement.) :) Cheers, -- Dan From reiner.pope at gmail.com Thu Nov 13 07:54:41 2008 From: reiner.pope at gmail.com (Reiner Pope) Date: Thu Nov 13 07:49:07 2008 Subject: [Haskell-cafe] Getting rid of functional dependencies with type proxies In-Reply-To: <698E8783CC407F4EB0DC9E994B6D4540D4B4AE@nut.avalanchestudios.se> References: <698E8783CC407F4EB0DC9E994B6D4540D4B4AE@nut.avalanchestudios.se> Message-ID: <4cf038ee0811130454u5d5f1147r29668c90d7a4f59c@mail.gmail.com> On Thu, Nov 13, 2008 at 9:09 PM, Tobias Bexelius wrote: > Hi, > > some time ago I asked about a problem I had with functional dependencies > conflicting when using overlapping instances in a code like this: > > > {-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances > -fallow-incoherent-instances #-} > data V2 a = V2 a a > class Vec v a where > dot :: v a -> v a -> a > instance Num a => Vec V2 a where > V2 a1 a2 `dot` V2 b1 b2 = a1*b1+a2*b2 > class Mult a b c | a b -> c where > (*.) :: a -> b -> c > instance (Num x) => Mult x x x where (*.) = (*) > instance (Vec a x) => Mult (a x) (a x) x where (*.) = dot > > {- > Functional dependencies conflict between instance declarations: > instance [overlap ok] (Num x) => Mult x x x > instance [overlap ok] (Vec a x) => Mult (a x) (a x) x > -} > > The problem here is that the dependency check is occuring too soon. > Removing the dependency would solve the problem, but then you would need > to put type annotations everywhere you use the multiplication operator, > and that's not acceptable. > However, I did found a solution I would like to share with you: Creating > a "type proxy"! I find it strange that such a simple solution to such a > (for me at least) common problem hasn't been documented more. > This is the working code: > > {-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances > -fallow-incoherent-instances #-} > data V2 a = V2 a a > class Vec v a where > dot :: v a -> v a -> a > instance Num a => Vec V2 a where > V2 a1 a2 `dot` V2 b1 b2 = a1*b1+a2*b2 > class Mult a b c | a b -> c where > (*.) :: a -> b -> c > class MultProxy a b c where > (*..) :: a -> b -> c > instance MultProxy a b c => Mult a b c where > (*.) = (*..) > instance (Num x) => MultProxy x x x where (*..) = (*) > instance (Vec a x) => MultProxy (a x) (a x) x where (*..) = dot > > > Thanks to Emil Axelsson that pointed me to > http://haskell.org/haskellwiki/GHC/AdvancedOverlap, where similar > problems where discussed. Again, I haven't found links to this page in > any of the Haskell tutorials I've read so far. > > /Tobias > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > Hi, I'm not convinced your solution actually preserves the fundeps as you might expect. What I've taken to "test" the fundeps have been the following two functions: (of course, we need the following extensions to have sensible type inference) > {-# OPTIONS -fglasgow-exts #-} > {-# LANGUAGE NoMonomorphismRestriction #-} > > foo x y = x *. y where > _ = x * y The "_ = x * y" clause ensures that x's type has a Num constraint. Depending on the setup, different types will be inferred by GHCi for foo. Consider your initial code, which didn't working because of conflicting instances. If you remove the (Vec a x)=>... instance, then the code compiles. With the fundeps, then foo's type is inferred as > foo :: Num a => a -> a -> a However, with your new Proxy-based code, foo's type is inferred as > foo :: (Num a, MultProxy a a c) => a -> a -> c so some of the fundep information has been "lost", in some sense. If you will consider using type equality constraints (which come with GHC 6.10) then there is another solution which I personally find more understandable than the fundeps/proxies approach. Write the classes as > class Mult a b c where > (*.) :: a -> b -> c > > instance (x ~ y, Num x) => Mult x x y where > (*.) = (*) > > instance (x ~ y, Vec a x) => Mult (a x) (a x) y where > (*.) = dot (Note that this doesn't require UndecidableInstances.) What's intuitively going on here is that the equality constraint in the instances acts similarly to a fundep (in that, if x is determined, then y is determined), but it's like a fundep /within the instance/. Thus, there is no "conflicting instances" problem, yet the fundep-like more-precise inference still works once we've selected an instance. Note that we do need to select an instance first; this requires IncoherentInstances, which you had in your code anyway. As long as IncoherentInstances is enabled, then foo's type is inferred as > foo :: Num a => a -> a -> a as required. As I said, I personally find type equality constraints much easier to reason about than fundeps, so I like using them for this kind of problem. Cheers, Reiner From lennart at augustsson.net Thu Nov 13 12:43:43 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Nov 13 12:38:08 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <20081112194058.zl9dncky884cks08-nwo@webmail.spamcop.net> References: <1226399902.6496.9.camel@rubix.office.last.fm> <491969F4.6000300@jellybean.co.uk> <594c1e830811121401m6624654h4c03dd50abf671b1@mail.gmail.com> <20081112194058.zl9dncky884cks08-nwo@webmail.spamcop.net> Message-ID: People have been admitting to using Haskell like that for quite a while now. I think it's an excellent use of Haskell as a DSEL host. -- Lennart On Thu, Nov 13, 2008 at 12:40 AM, wrote: > G'day all. > > Quoting Tom Hawkins : > >> Actually, Haskell is an excellent language for hard real-time >> applications. At Eaton we're using it for automotive powertrain >> control. Of course, the RTS is not running in the loop. Instead, we >> write in a DSL, which generates C code for our vehicle ECU. > > Bingo! And thanks for someone for admitting that they do this. :-) > "Hard real-time applications" is a huge area, and not all of the code > that you write is code that ends up running on the target. > > Generally, in DSL/MDD-style development, not very much of the code that > you write ends up running on the target. In some cases, _none_ of the > code you write ends up running on the target. Haskell is almost ideal > for tasks like this. > > Cheers, > Andrew Bromage > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From darrinth at gmail.com Thu Nov 13 13:46:14 2008 From: darrinth at gmail.com (Darrin Thompson) Date: Thu Nov 13 13:40:38 2008 Subject: [Haskell-cafe] The Gtk Clutter API Message-ID: http://www.clutter-project.org/ What is the degree-of-difficulty for creating Haskell bindings for Clutter? Is it simple to extend gtk2hs to cover it? Or has it been done and I just don't see it? Thanks. -- Darrin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081113/3dc38a1a/attachment.htm From dpiponi at gmail.com Thu Nov 13 13:58:33 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Thu Nov 13 13:52:58 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <4e7aa0f80811111941k32f80909ld7cec678d6a1b8a8@mail.gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <491A3953.7090305@freegeek.org> <4e7aa0f80811111941k32f80909ld7cec678d6a1b8a8@mail.gmail.com> Message-ID: <625b74080811131058x30a6ca1dx94d232190cef4a1c@mail.gmail.com> Real time audio applications are top of my list of "crazy projects I would work on if I had a month spare". I think it might work out nicely. My approach wouldn't be to talk directly to audio hardware from Haskell but instead use a framework like Lava to generate low level code from an embedded DSL. I think that would be a really elegant way to work at a high level and yet have the result execute *faster* than traditionally written C++ code. -- Dan On Tue, Nov 11, 2008 at 7:41 PM, sam lee wrote: > I haven't found multitrack audio recording applications written in > Haskell. These are usually written in C++ using Jack audio or ASIO. > This probably means that it is not a good idea to write real time > audio applications in Haskell at the moment. > So, probably avoid writing applications that use a high frequency > timer and IO that should be synchronous to the timer in Haskell. > > On Tue, Nov 11, 2008 at 9:02 PM, wren ng thornton wrote: >> Dave Tapley wrote: >>> >>> Hi everyone >>> >>> So I should clarify I'm not a troll and do "see the Haskell light". But >>> one thing I can never answer when preaching to others is "what does >>> Haskell not do well?" >>> >>> Usually I'll avoid then question and explain that it is a 'complete' >>> language and we do have more than enough libraries to make it useful and >>> productive. But I'd be keen to know if people have any anecdotes, >>> ideally ones which can subsequently be twisted into an argument for >>> Haskell ;) >> >> With the appropriate caveats about particular subdomains (see final >> paragraph), I wouldn't use Haskell for scripting. That is, (1) for >> Bash-style programming where 95% of the code is just invoking *nix jobs, or >> (2) for very simple yet regex-heavy scripts where Perl/Awk/Sed is often >> used. >> >> Re #1: Honestly, I don't see anything other than a dedicated competitor >> being able to unseat Bourne/Bash at this task. Certainly a competitor would >> have much room for improvement-- what with being able to replace >> string-rewriting semantics with term-rewriting semantics, vastly improving >> type safety and catching innumerable bugs. However, with unsavory frequency, >> it is exactly those type-unsafe substitutions which can make shell scripting >> cleaner and more direct than a type-safe alternative. Having type safety as >> well as this sort of non-compositional structure would take a good deal of >> work to get right. >> >> Re #2: People often complain about spooky Perl that uses things like >> implicit $_ or other hidden variables. While these constructs can make any >> sizable project unmaintainable, for the quick and dirty jobs they're just >> what's needed to get things done with clarity. While ByteString code using >> regexes is just as fast in Haskell, it's often more than twice as long as >> the Perl, Sed, or Awk equivalents because many of the basic control >> structures (like Perl's -n, -p, -l,... flags) aren't already provided. >> >> >> That said, this isn't necessarily a bad thing for Haskell. "Real" >> programming languages often don't do so well in these areas (Perl being the >> exception), and they don't feel too bad about it. Both varieties of shell >> scripting are very much of the DSL nature; for programs with a significant >> amount of "actual logic" instead of mere plumbing or regexing, Haskell can >> certainly outshine these competitors. On the one hand, C and friends fight >> dirty and much work has been done so Haskell can join in on the bit-bashing >> glory. However, shell scripting is a whole different kind of imperative muck >> and very little work (that I've seen) has tried to get Haskell to jump down >> in the sewers with them. >> >> -- >> Live well, >> ~wren >> _______________________________________________ >> 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 andrewcoppin at btinternet.com Thu Nov 13 14:08:42 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Nov 13 14:03:07 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <625b74080811131058x30a6ca1dx94d232190cef4a1c@mail.gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <491A3953.7090305@freegeek.org> <4e7aa0f80811111941k32f80909ld7cec678d6a1b8a8@mail.gmail.com> <625b74080811131058x30a6ca1dx94d232190cef4a1c@mail.gmail.com> Message-ID: <491C7B3A.1060804@btinternet.com> Dan Piponi wrote: > Real time audio applications are top of my list of "crazy projects I > would work on if I had a month spare". I think it might work out > nicely. My approach wouldn't be to talk directly to audio hardware > from Haskell but instead use a framework like Lava to generate low > level code from an embedded DSL. I think that would be a really > elegant way to work at a high level and yet have the result execute > *faster* than traditionally written C++ code. > In other words, Haskell is an excellent language for designing special-purpose compilers and interpretters for custom languages. ;-) If I knew a damned thing about IA32 assembly and dynamic linkage, I'd be tempted to try it myself... From dons at galois.com Thu Nov 13 14:13:59 2008 From: dons at galois.com (Don Stewart) Date: Thu Nov 13 14:08:24 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <491C7B3A.1060804@btinternet.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <491A3953.7090305@freegeek.org> <4e7aa0f80811111941k32f80909ld7cec678d6a1b8a8@mail.gmail.com> <625b74080811131058x30a6ca1dx94d232190cef4a1c@mail.gmail.com> <491C7B3A.1060804@btinternet.com> Message-ID: <20081113191359.GE3949@scytale.galois.com> andrewcoppin: > Dan Piponi wrote: > >Real time audio applications are top of my list of "crazy projects I > >would work on if I had a month spare". I think it might work out > >nicely. My approach wouldn't be to talk directly to audio hardware > >from Haskell but instead use a framework like Lava to generate low > >level code from an embedded DSL. I think that would be a really > >elegant way to work at a high level and yet have the result execute > >*faster* than traditionally written C++ code. > > > > In other words, Haskell is an excellent language for designing > special-purpose compilers and interpretters for custom languages. ;-) > > If I knew a damned thing about IA32 assembly and dynamic linkage, I'd be > tempted to try it myself... No need, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/harpy Well, you still should probably know something of what you're doing.. From bartek at sudety.it Thu Nov 13 16:08:19 2008 From: bartek at sudety.it (Bartosz =?iso-8859-1?q?W=F3jcik?=) Date: Thu Nov 13 15:02:51 2008 Subject: [Haskell-cafe] Problem with directory-1.0.0.0 Message-ID: <200811132208.20012.bartek@sudety.it> Hi Folks, I'm facing problem after I've reinstalled directory-1.0.0.0 (setup configure/build/install). Since then I cannot complie anything that needs this library. It fails with following messages: Preprocessing library haddock-2.4.0... Preprocessing executables for haddock-2.4.0... Building haddock-2.4.0... /usr/bin/ar: creating dist/build/libHShaddock-2.4.0.a Linking dist/build/haddock/haddock ... /usr/local/lib/ghc-6.8.2/libHSghc.a(Coverage.o): In function `scXR_info': (.text+0x17b7c): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_lvl29_closure' /usr/local/lib/ghc-6.8.2/libHSghc.a(Coverage.o): In function `s8xU_info': (.text+0x1792c): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a43_info' /usr/local/lib/ghc-6.8.2/libHSghc.a(Coverage.o): In function `r7aC_closure': (.data+0xd18): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a43_closure' collect2: ld returned 1 exit status Situation is following: Old directory-1.0.0.0 resides in /usr/local/lib/ghc-6.8.2/lib/directory-1.0.0.0. New one in /usr/local/lib/directory-1.0.0.0. Why new one doesn't work? How to force linker to use old one? Best, Bartek From analytic at gmail.com Thu Nov 13 16:01:36 2008 From: analytic at gmail.com (Stephen) Date: Thu Nov 13 15:56:01 2008 Subject: [Haskell-cafe] openal & alut troubles Message-ID: The link to the OpenAL documentation [ http://haskell.org/ghc/docs/latest/html/libraries/OpenAL/Sound-OpenAL.html ] from here [ http://www.haskell.org/haskellwiki/OpenAL ] seems to be down. Also, I tried to use cabal to install ALUT and got the following checking for unistd.h... yes checking AL/alut.h usability... no checking AL/alut.h presence... no checking for AL/alut.h... no checking OpenAL/alut.h usability... no checking OpenAL/alut.h presence... no checking for OpenAL/alut.h... no configure: error: no ALUT header found, so this package cannot be built See `config.log' for more details. cabal: Error: some packages failed to install: ALUT-2.1.0.0 failed during the configure step. The exception was: exit: ExitFailure 1 :/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081113/5bd12274/attachment.htm From dpiponi at gmail.com Thu Nov 13 16:06:54 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Thu Nov 13 16:01:18 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <491C7B3A.1060804@btinternet.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <491A3953.7090305@freegeek.org> <4e7aa0f80811111941k32f80909ld7cec678d6a1b8a8@mail.gmail.com> <625b74080811131058x30a6ca1dx94d232190cef4a1c@mail.gmail.com> <491C7B3A.1060804@btinternet.com> Message-ID: <625b74080811131306x1bbc8bfdg42fac7601021c552@mail.gmail.com> On Thu, Nov 13, 2008 at 11:08 AM, Andrew Coppin wrote: > In other words, Haskell is an excellent language for designing > special-purpose compilers and interpretters for custom languages. ;-) > > If I knew a damned thing about IA32 assembly and dynamic linkage, I'd be > tempted to try it myself... You could generate assembly language instructions directly. But if you use the Haskell LLVM bindings your generated code will be (1) platform independent and (2) optimised. I think there's a cool project lurking there. -- Dan From bartek at sudety.it Thu Nov 13 17:07:42 2008 From: bartek at sudety.it (Bartosz =?iso-8859-1?q?W=F3jcik?=) Date: Thu Nov 13 16:02:13 2008 Subject: [Haskell-cafe] Problem with directory-1.0.0.0 In-Reply-To: <200811132208.20012.bartek@sudety.it> References: <200811132208.20012.bartek@sudety.it> Message-ID: <200811132307.42708.bartek@sudety.it> OK, I've found package.conf file and updated there libraries manually. Why new one doesn't work I don't know though. If anyone can have an idea, it'd be helpful. best, Bartek On Thursday 13 November 2008 22:08:19 Bartosz W?jcik wrote: > I'm facing problem after I've reinstalled directory-1.0.0.0 (setup > configure/build/install). Since then I cannot complie anything that needs > this library. It fails with following messages: > > Preprocessing library haddock-2.4.0... > Preprocessing executables for haddock-2.4.0... > Building haddock-2.4.0... > /usr/bin/ar: creating dist/build/libHShaddock-2.4.0.a >Situation is following: >Old directory-1.0.0.0 resides >in /usr/local/lib/ghc-6.8.2/lib/directory-1.0.0.0. >New one in /usr/local/lib/directory-1.0.0.0. >Why new one doesn't work? >How to force linker to use old one? From ajb at spamcop.net Thu Nov 13 18:38:56 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Thu Nov 13 18:33:19 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: References: <1226399902.6496.9.camel@rubix.office.last.fm> <491969F4.6000300@jellybean.co.uk> <594c1e830811121401m6624654h4c03dd50abf671b1@mail.gmail.com> <20081112194058.zl9dncky884cks08-nwo@webmail.spamcop.net> Message-ID: <20081113183856.7lbsyj17kkgcsk8s-nwo@webmail.spamcop.net> G'day all. Quoting Lennart Augustsson : > People have been admitting to using Haskell like that for quite a while now. > I think it's an excellent use of Haskell as a DSEL host. DSL is a proper superset of DSEL. Just saying. Cheers, Andrew Bromage From marco-oweber at gmx.de Thu Nov 13 19:53:32 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu Nov 13 19:47:57 2008 Subject: [Haskell-cafe] openal & alut troubles In-Reply-To: References: Message-ID: <20081114005332.GD10874@gmx.de> On Thu, Nov 13, 2008 at 09:01:36PM +0000, Stephen wrote: > The link to the OpenAL documentation [ > [1]http://haskell.org/ghc/docs/latest/html/libraries/OpenAL/Sound-OpenAL.html > ] from here [ [2]http://www.haskell.org/haskellwiki/OpenAL ] seems to be > down. > > Also, I tried to use cabal to install ALUT and got the following > > checking for unistd.h... yes > checking AL/alut.h usability... no > checking AL/alut.h presence... no > checking for AL/alut.h... no > checking OpenAL/alut.h usability... no > checking OpenAL/alut.h presence... no > checking for OpenAL/alut.h... no > configure: error: no ALUT header found, so this package cannot be built ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'm not sure what you're asking. It seems that you either don't have alut installed or configure doesn't know about it.. Good luck Marc Weber From dagit at codersbase.com Thu Nov 13 20:54:06 2008 From: dagit at codersbase.com (Jason Dagit) Date: Thu Nov 13 20:48:28 2008 Subject: [Haskell-cafe] What is Haskell used for? Message-ID: I was looking over the Hackage categories today to figure out what Haskell is *really* used for? I just really quickly sorted the categories by number of packages. It's really interesting to see System, Graphics and Network so high on the list. Clearly, next to data types and text processing, people are doing systems, graphics and network programming. C had better watch out! Jason Categories: Data (89) Text (84) System (83) Graphics (50) Network (48) Development (45) Web (41) Control (37) Language (36) Math (36) Database (33) Sound (31) Codec (26) Game (26) User Interfaces (23) Unclassified (22) Parsing (19) Compilers/Interpreters (16) Data Structures (16) Distribution (15) Testing (15) Algorithms (12) XML (12) Natural Language Processing (10) Monads (9) Pugs (9) Bioinformatics (8) Generics (8) GUI (8) Hardware (3) Foreign (7) FRP (6) Concurrency (6) Reactivity (5) Distributed Computing (5) Source-tools (5) Music (4) Cryptography (4) Editor (4) Interfaces (4) Physics (4) AI (3) Code Generation (3) Codecs (3) Other (3) Search (3) List (2) Data Mining (2) Combinators (2) Console (2) Debug (2) Numerical (2) Theorem Provers (2) Utils (2) Comonads (1) Composition (1) Desktop (1) FFI Tools (1) Finance (1) Help (1) Middleware (1) Monadic Regions (1) Numeric (1) Screensaver (1) Scripting (1) System.Console (1) Test (1) Trace (1) User-interface (1) From sanzhiyan at gmail.com Thu Nov 13 21:01:28 2008 From: sanzhiyan at gmail.com (sanzhiyan@gmail.com) Date: Thu Nov 13 20:55:52 2008 Subject: [Haskell-cafe] Monads for Incremental computing Message-ID: <000e0cd2474a7db93a045b9c9b56@google.com> I'm looking for the source code of the library for adaptive computations exposed in Magnus Carlsson's "Monads for Incremental Computing"[1], but the link in the paper is broken. So, does anyone have the sources or knows how to contact the author? [1] http://portal.acm.org/citation.cfm?id=581482 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081113/2a3675a0/attachment.htm From dons at galois.com Thu Nov 13 21:02:40 2008 From: dons at galois.com (Don Stewart) Date: Thu Nov 13 20:57:07 2008 Subject: [Haskell-cafe] Monads for Incremental computing In-Reply-To: <000e0cd2474a7db93a045b9c9b56@google.com> References: <000e0cd2474a7db93a045b9c9b56@google.com> Message-ID: <20081114020240.GB6645@scytale.galois.com> I sit next to the author, CC'd. -- Don sanzhiyan: > I'm looking for the source code of the library for adaptive computations > exposed in Magnus Carlsson's "Monads for Incremental Computing"[1], but > the link in the paper is broken. > So, does anyone have the sources or knows how to contact the author? > > [1] http://portal.acm.org/citation.cfm?id=581482 > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From donnie at darthik.com Thu Nov 13 21:07:06 2008 From: donnie at darthik.com (Donnie Jones) Date: Thu Nov 13 21:01:30 2008 Subject: [Haskell-cafe] Monads for Incremental computing In-Reply-To: <20081114020240.GB6645@scytale.galois.com> References: <000e0cd2474a7db93a045b9c9b56@google.com> <20081114020240.GB6645@scytale.galois.com> Message-ID: Hello sanzhiyan, I believe this is the same paper, the pdf is available here: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.8.3014 Cheers. __ Donnie On Thu, Nov 13, 2008 at 9:02 PM, Don Stewart wrote: > I sit next to the author, CC'd. > > -- Don > > sanzhiyan: > > I'm looking for the source code of the library for adaptive > computations > > exposed in Magnus Carlsson's "Monads for Incremental Computing"[1], > but > > the link in the paper is broken. > > So, does anyone have the sources or knows how to contact the author? > > > > [1] http://portal.acm.org/citation.cfm?id=581482 > > > _______________________________________________ > > 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/20081113/4ba4562e/attachment.htm From lists at qseep.net Thu Nov 13 21:17:57 2008 From: lists at qseep.net (Lyle Kopnicky) Date: Thu Nov 13 21:12:19 2008 Subject: [Haskell-cafe] Re: TimeDiff to Int? In-Reply-To: References: <670e468e0811120810g26481a76tb1dddf274c11fa0f@mail.gmail.com> Message-ID: <670e468e0811131817w43ec00fdk83c6290100a34310@mail.gmail.com> Thanks, but that doesn't seem to work. I got an answer of -3. I tried it again a minute later and it was still -3. I tried again a minute later and it was -1. It's just after 9am here, so I have no idea what to make of those numbers. I have settled on this code: secondsSinceMidnight :: IO Int secondsSinceMidnight = do zonedTime <- getZonedTime return $ floor $ toRational $ timeOfDayToTime $ localTimeOfDay $ zonedTimeToLocalTime zonedTime On Thu, Nov 13, 2008 at 2:29 AM, Jon Fairbairn wrote: > "Lyle Kopnicky" writes: > > > I had some code using the oldtime package, and want to convert it to use > > the time package. > > One of the things I need to do is calculate the number of seconds since > > midnight. The easy part is getting a TimeDiff result: > > You mean DiffTime? > > > utc <- getCurrentTime > > tz <- getCurrentTimeZone > > let td = timeOfDayToTime $ localTimeOfDay $ utcToLocalTime tz utc > > Now td is a TimeDiff representation of the number of seconds since > > midnight. It prints nicely, but I'm having a heck of a time figuring out > > how to truncate it to an Int. > > You could do something like > fromEnum td `div` fromEnum (secondsToDiffTime 1) > which says that you are computing a whole number of seconds. > > -- > J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk > http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2008-04-26) > > _______________________________________________ > 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/20081113/0e8fa61b/attachment.htm From analytic at gmail.com Thu Nov 13 21:33:05 2008 From: analytic at gmail.com (Stephen) Date: Thu Nov 13 21:27:29 2008 Subject: [Haskell-cafe] openal & alut troubles In-Reply-To: <20081114005332.GD10874@gmx.de> References: <20081114005332.GD10874@gmx.de> Message-ID: ah, damn I feel stupid. I hadn't it installed. I just tried to, and, after verifying with the internet, it seems that ALUT isn't supported on macs anymore anyway. Which leads me to the following question: does anyone have any example code for saving/loading wav files, say, using openal (minus alut) with haskell? I'm not too sure how to go about doing it myself (though the people on this thread http://groups.google.com/group/fa.haskell/browse_thread/thread/33b57c945274e353/a5d6094ff448a956?#a5d6094ff448a956seem to indicate that it would be a relatively easy task). On Fri, Nov 14, 2008 at 12:53 AM, Marc Weber wrote: > On Thu, Nov 13, 2008 at 09:01:36PM +0000, Stephen wrote: > > The link to the OpenAL documentation [ > > [1] > http://haskell.org/ghc/docs/latest/html/libraries/OpenAL/Sound-OpenAL.html > > ] from here [ [2]http://www.haskell.org/haskellwiki/OpenAL ] seems to > be > > down. > > > > Also, I tried to use cabal to install ALUT and got the following > > > > checking for unistd.h... yes > > checking AL/alut.h usability... no > > checking AL/alut.h presence... no > > checking for AL/alut.h... no > > checking OpenAL/alut.h usability... no > > checking OpenAL/alut.h presence... no > > checking for OpenAL/alut.h... no > > configure: error: no ALUT header found, so this package cannot be > built > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I'm not sure what you're asking. It seems that you either don't have > alut installed or configure doesn't know about it.. > > Good luck > > Marc Weber > _______________________________________________ > 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/20081114/e3ba0d0b/attachment.htm From dons at galois.com Thu Nov 13 22:46:01 2008 From: dons at galois.com (Don Stewart) Date: Thu Nov 13 22:40:25 2008 Subject: [magnus@galois.com: Re: [Haskell-cafe] Monads for Incremental computing] Message-ID: <20081114034601.GA7110@scytale.galois.com> Magnus writes: Thanks to Peter Jonsson, the source is now on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Adaptive Cheers, Magnus Donnie Jones wrote: > Hello sanzhiyan, > > I believe this is the same paper, the pdf is available here: > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.8.3014 > > Cheers. > __ > Donnie > > On Thu, Nov 13, 2008 at 9:02 PM, Don Stewart > wrote: > > I sit next to the author, CC'd. > > -- Don > > sanzhiyan: > > I'm looking for the source code of the library for adaptive > computations > > exposed in Magnus Carlsson's "Monads for Incremental > Computing"[1], but > > the link in the paper is broken. > > So, does anyone have the sources or knows how to contact the > author? > > > > [1] http://portal.acm.org/citation.cfm?id=581482 > > > _______________________________________________ > > 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 > > ----- End forwarded message ----- From conal at conal.net Fri Nov 14 00:24:29 2008 From: conal at conal.net (Conal Elliott) Date: Fri Nov 14 00:18:52 2008 Subject: [magnus@galois.com: Re: [Haskell-cafe] Monads for Incremental computing] In-Reply-To: <20081114034601.GA7110@scytale.galois.com> References: <20081114034601.GA7110@scytale.galois.com> Message-ID: As Magnus pointed out in his (very clever) paper, the Applicative interface allows for more precise/efficient tracking of dependencies, in that it eliminates accidental sequentiality imposed by the Monad interface. (Magnus didn't mention Applicative by name, as his paper preceded Idiom/Applicative.) However, I don't see an Applicative instance in the library. - Conal On Thu, Nov 13, 2008 at 7:46 PM, Don Stewart wrote: > Magnus writes: > > Thanks to Peter Jonsson, the source is now on hackage: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Adaptive > > Cheers, > Magnus > > > Donnie Jones wrote: > > Hello sanzhiyan, > > > > I believe this is the same paper, the pdf is available here: > > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.8.3014 > > > > Cheers. > > __ > > Donnie > > > > On Thu, Nov 13, 2008 at 9:02 PM, Don Stewart > > wrote: > > > > I sit next to the author, CC'd. > > > > -- Don > > > > sanzhiyan: > > > I'm looking for the source code of the library for adaptive > > computations > > > exposed in Magnus Carlsson's "Monads for Incremental > > Computing"[1], but > > > the link in the paper is broken. > > > So, does anyone have the sources or knows how to contact the > > author? > > > > > > [1] http://portal.acm.org/citation.cfm?id=581482 > > > > > _______________________________________________ > > > 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 > > > > > > ----- End forwarded message ----- > _______________________________________________ > 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/20081113/71e64742/attachment.htm From marco-oweber at gmx.de Fri Nov 14 02:11:59 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Fri Nov 14 02:06:24 2008 Subject: [Haskell-cafe] openal & alut troubles In-Reply-To: References: <20081114005332.GD10874@gmx.de> Message-ID: <20081114071159.GB18112@gmx.de> On Fri, Nov 14, 2008 at 02:33:05AM +0000, Stephen wrote: > ah, damn I feel stupid. I hadn't it installed. I just tried to, and, > after verifying with the internet, it seems that ALUT isn't supported on > macs anymore anyway. Which leads me to the following question: does > anyone have any example code for saving/loading wav files, say, using > openal (minus alut) with haskell? I'm not too sure how to go about > doing it myself (though the people on this thread > [1]http://groups.google.com/group/fa.haskell/browse_thread/thread/33b57c945274e353/a5d6094ff448a956?#a5d6094ff448a956 > seem to indicate that it would be a relatively easy task). Wave files are realitively easy to write .. However you can also try the encoder from hackage (catergory sound) called HSoundFile.. (I've never used it before) Also using the haskell wiki search from haskell.org reveals: http://haskell.org/haskellwiki/Sound_data_structures good luck Marc From cetin.sert at gmail.com Fri Nov 14 02:17:59 2008 From: cetin.sert at gmail.com (Cetin Sert) Date: Fri Nov 14 02:12:23 2008 Subject: [Haskell-cafe] ghci start-up banner Message-ID: <1ff5dedc0811132317n6b7871bcx491739e1c7971620@mail.gmail.com> Hi all, after reading this announcement on the Galois blog: http://www.galois.com/blog/2008/11/13/tech-talk-mechanically-verified-lisp-interpreters/ I installed Hol4 to play around with it a little bit. I made 2 obvious observations ^_^: 1) It looks like the Hol4 system is just a ML module that gets loaded into the Moscow ML interpreter with the help of a script 2) it prints a custom banner after loading And now I have the following questions: == about proof assistants in general == 1) how many other proof assistants are built the same way as Hol4: as a module loaded into some interpreter? 2) is there a paper or even better a funny but detailed comparison of proof assistants? == about custom banners at module load time == 1) is there a way to do it in ghci? Regards, CS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081114/f95bd557/attachment.htm From colin at colina.demon.co.uk Fri Nov 14 03:03:04 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Fri Nov 14 02:57:28 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? In-Reply-To: (Colin Paul Adams's message of "Tue\, 11 Nov 2008 20\:07\:55 +0000") References: <457DB857-8E23-4DF3-964E-D54183B732EA@pikewerks.com> <1226428505.12478.3.camel@derek-laptop> <20081111193106.GA23562@hustlerturf.com> Message-ID: >>>>> "Colin" == Colin Paul Adams writes: Colin> And thanks everyone for your help. I have enough to go on Colin> now. I followed the example at http://www.haskell.org/haskellwiki/Calling_Haskell_from_C (and renamed the files from A* to fib1*, as I want to pursue this further). But I get: fib1.o: In function `main': fib1.c:(.text+0x0): multiple definition of `main' fib1.o:fib1.c:(.text+0x0): first defined here fib1_stub.o: In function `stginit_export_Safe_zdffibonaccizuhszuaDN': fib1_stub.c:(.text+0x5): undefined reference to `Safe_zdffibonaccizuhszuaDN_closure' fib1_stub.o: In function `fibonacci_hs': fib1_stub.c:(.text+0x32): undefined reference to `Safe_zdffibonaccizuhszuaDN_closure' collect2: ld returned 1 exit status -- Colin Adams Preston Lancashire From dons at galois.com Fri Nov 14 03:06:10 2008 From: dons at galois.com (Don Stewart) Date: Fri Nov 14 03:00:53 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? In-Reply-To: References: <457DB857-8E23-4DF3-964E-D54183B732EA@pikewerks.com> <1226428505.12478.3.camel@derek-laptop> <20081111193106.GA23562@hustlerturf.com> Message-ID: <20081114080610.GB8133@scytale.galois.com> colin: > >>>>> "Colin" == Colin Paul Adams writes: > > Colin> And thanks everyone for your help. I have enough to go on > Colin> now. > > I followed the example at > http://www.haskell.org/haskellwiki/Calling_Haskell_from_C > > (and renamed the files from A* to fib1*, as I want to pursue this > further). > > But I get: > > fib1.o: In function `main': > fib1.c:(.text+0x0): multiple definition of `main' > fib1.o:fib1.c:(.text+0x0): first defined here > fib1_stub.o: In function `stginit_export_Safe_zdffibonaccizuhszuaDN': > fib1_stub.c:(.text+0x5): undefined reference to `Safe_zdffibonaccizuhszuaDN_closure' > fib1_stub.o: In function `fibonacci_hs': > fib1_stub.c:(.text+0x32): undefined reference to `Safe_zdffibonaccizuhszuaDN_closure' > collect2: ld returned 1 exit status Not linking in the 'Safe' module on the command line? -- Don From colin at colina.demon.co.uk Fri Nov 14 03:11:21 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Fri Nov 14 03:05:44 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? In-Reply-To: <20081114080610.GB8133@scytale.galois.com> (Don Stewart's message of "Fri\, 14 Nov 2008 00\:06\:10 -0800") References: <457DB857-8E23-4DF3-964E-D54183B732EA@pikewerks.com> <1226428505.12478.3.camel@derek-laptop> <20081111193106.GA23562@hustlerturf.com> <20081114080610.GB8133@scytale.galois.com> Message-ID: >>>>> "Don" == Don Stewart writes: Don> Not linking in the 'Safe' module on the command line? Could be - I don't know any of this stuff. I was just following the instructions on the wiki page. How should these be amended? -- Colin Adams Preston Lancashire From ryani.spam at gmail.com Fri Nov 14 03:51:57 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Fri Nov 14 03:46:19 2008 Subject: [magnus@galois.com: Re: [Haskell-cafe] Monads for Incremental computing] In-Reply-To: References: <20081114034601.GA7110@scytale.galois.com> Message-ID: <2f9b2d30811140051v542b36acp4e16c0bb41fc5d66@mail.gmail.com> 2008/11/13 Conal Elliott : > As Magnus pointed out in his (very clever) paper, the Applicative interface > allows for more precise/efficient tracking of dependencies, in that it > eliminates accidental sequentiality imposed by the Monad interface. (Magnus > didn't mention Applicative by name, as his paper preceded > Idiom/Applicative.) However, I don't see an Applicative instance in the > library. I was wondering about that, actually. The specialized Applicative instance mentioned in the paper adds an additional storage cell to the computation graph. I would expect that for simple computations, using the applicative instance could perform worse than "naive" monadic code. For example, given three adaptive references "ref1", "ref2", and "ref3" :: Adaptive Int do a <- ref1 b <- ref2 c <- ref3 return (a+b+c) This computation adds three "read" nodes to the current "write" output. But this code: do (\a b c -> a + b + c) <$> read ref1 <*> read ref2 <*> read ref3 using (<*>) = the enhanced version of "ap" from the paper. I believe this would allocate additional cells to hold the results of the function partially applied to the intermediate computations. Overall I think this would not be a win in this case. But it is also easy to construct cases where it *is* a win. I suppose you can allow the user to choose one or the other, but my general expectation for Applicative is that (<*>) should never perform *worse* than code that uses Control.Monad.ap Is this the right understanding, or am I totally missing something from the Adaptive paper? -- ryan From jon.fairbairn at cl.cam.ac.uk Fri Nov 14 05:06:23 2008 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Fri Nov 14 05:00:54 2008 Subject: [Haskell-cafe] Re: TimeDiff to Int? References: <670e468e0811120810g26481a76tb1dddf274c11fa0f@mail.gmail.com> <670e468e0811131817w43ec00fdk83c6290100a34310@mail.gmail.com> Message-ID: "Lyle Kopnicky" writes: > Thanks, but that doesn't seem to work. I got an answer of -3. I tried it > again a minute later and it was still -3. I tried again a minute later and > it was -1. It's just after 9am here, so I have no idea what to make of > those numbers. That's most strange. The only difference between what I wrote and what you had before was the way the conversion to Integer was done. > I have settled on this code: > > secondsSinceMidnight :: IO Int > secondsSinceMidnight = do > zonedTime <- getZonedTime > return $ floor $ toRational $ timeOfDayToTime $ localTimeOfDay $ > zonedTimeToLocalTime zonedTime So what happens with do now <- getZonedTime; print $ (fromEnum $ timeOfDayToTime $ localTimeOfDay $ zonedTimeToLocalTime now)`div`fromEnum (secondsToDiffTime 1) where you are? -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From will at willthompson.co.uk Fri Nov 14 05:44:39 2008 From: will at willthompson.co.uk (Will Thompson) Date: Fri Nov 14 05:39:22 2008 Subject: [Haskell-cafe] ANN: bustle-0.1, a D-Bus activity charting tool Message-ID: <491D5697.1060404@willthompson.co.uk> Hi, For the (probably small) set of people who are interested both in D-Bus and in Haskell, I'm pleased to announce the first release of Bustle, a tool to show diagrams of D-Bus traffic for profiling purposes. It consists of a small C executable to log traffic, and a Gtk+ application which draws diagrams using Cairo. There's no single web page for it yet. http://resiak.livejournal.com/59590.html has slightly more information and context, the release is at http://people.collabora.co.uk/~wjt/bustle/releases/bustle-0.1.tar.gz and the source at git://git.collabora.co.uk/git/user/wjt/bustle.git . Unfortunately, it's not on Hackage, as I haven't written the necessary glue to get Cabal to compile the C executable, but I hope to have time to work on getting Cabal to invoke make appropriately for the next release. Thanks, -- Will -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081114/e00f1002/signature-0001.bin From schlepptop at henning-thielemann.de Fri Nov 14 06:33:02 2008 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Fri Nov 14 06:23:54 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <625b74080811131058x30a6ca1dx94d232190cef4a1c@mail.gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <491A3953.7090305@freegeek.org> <4e7aa0f80811111941k32f80909ld7cec678d6a1b8a8@mail.gmail.com> <625b74080811131058x30a6ca1dx94d232190cef4a1c@mail.gmail.com> Message-ID: <491D61EE.7050301@henning-thielemann.de> Dan Piponi schrieb: > Real time audio applications are top of my list of "crazy projects I > would work on if I had a month spare". I think it might work out > nicely. My approach wouldn't be to talk directly to audio hardware > from Haskell but instead use a framework like Lava to generate low > level code from an embedded DSL. I think that would be a really > elegant way to work at a high level and yet have the result execute > *faster* than traditionally written C++ code. > -- > Dan > > On Tue, Nov 11, 2008 at 7:41 PM, sam lee wrote: >> I haven't found multitrack audio recording applications written in >> Haskell. These are usually written in C++ using Jack audio or ASIO. >> This probably means that it is not a good idea to write real time >> audio applications in Haskell at the moment. >> So, probably avoid writing applications that use a high frequency >> timer and IO that should be synchronous to the timer in Haskell. I do real time audio processing based on lazy storable vectors, however I do not plan to implement another GUI driven program but want to program audio algorithms and music in Haskell. http://www.haskell.org/haskellwiki/Synthesizer Although I can do some processing in real-time I don't approach the speed of say SuperCollider so far. I must rely on GHC's optimizer and sometimes it does unexpected things. I know that one of Paul Hudak's students is working on something similar, called HasSound. The DSL approach is already implemented for CSound in Haskore (again there is also a not yet published library which encapsulates this functionality) and you can also do real time sound processing by controlling SuperCollider: http://www.haskell.org/haskellwiki/SuperCollider See also: http://www.haskell.org/haskellwiki/Category:Music From jwlato at gmail.com Fri Nov 14 10:49:57 2008 From: jwlato at gmail.com (John Lato) Date: Fri Nov 14 10:44:18 2008 Subject: [Haskell-cafe] Re: Haskell-Cafe Digest, Vol 63, Issue 23 In-Reply-To: <20081114103934.EFFA93246AB@www.haskell.org> References: <20081114103934.EFFA93246AB@www.haskell.org> Message-ID: <9979e72e0811140749q711ad5d6he9d1fb17b802ea27@mail.gmail.com> You could use HSoundFile, but I wouldn't recommend it for this specific case. I'm not extremely familiar with the Haskell OpenAL bindings, but IIRC they take buffers (pointers). Since HSoundFile marshals data to [Double], you'd then have to convert it back to CWord16 array. Seems wasteful and slow to me. Here are 3 possible approaches: 1. Look through HSoundFile (or similar) to learn how they work and write your own code. 2. Look at the Codecs or Wave packages, which might be coerced into doing what you want (there is also hsndfile, a binding to libsndfile, however I think that normalizes data like HSoundFile does, although you could likely avoid the marshaling problem. 3. I have a revised HSoundFile, which I think could be much more suitable for this sort of work. If you'd like the code for that, let me know and I'd be happy to pass it along. I'm hoping to do a release next week, but there's a lot of tidying to be done in the current state. How many people care about reading/writing audio files? I've been re-working the HSoundFile API, experimenting with different designs, comparing packages, etc., and I could do a write-up if anyone is interested. John Lato > > Message: 19 > Date: Fri, 14 Nov 2008 08:11:59 +0100 > From: Marc Weber > Subject: Re: [Haskell-cafe] openal & alut troubles > To: haskell-cafe@haskell.org > Message-ID: <20081114071159.GB18112@gmx.de> > Content-Type: text/plain; charset=utf-8 > > On Fri, Nov 14, 2008 at 02:33:05AM +0000, Stephen wrote: >> ah, damn I feel stupid. I hadn't it installed. I just tried to, and, >> after verifying with the internet, it seems that ALUT isn't supported on >> macs anymore anyway. Which leads me to the following question: does >> anyone have any example code for saving/loading wav files, say, using >> openal (minus alut) with haskell? I'm not too sure how to go about >> doing it myself (though the people on this thread >> [1]http://groups.google.com/group/fa.haskell/browse_thread/thread/33b57c945274e353/a5d6094ff448a956?#a5d6094ff448a956 >> seem to indicate that it would be a relatively easy task). > > Wave files are realitively easy to write .. However you can also try the > encoder from hackage (catergory sound) called HSoundFile.. (I've never > used it before) Also using the haskell wiki search from haskell.org > reveals: http://haskell.org/haskellwiki/Sound_data_structures > > good luck > > Marc From colin at colina.demon.co.uk Fri Nov 14 11:17:23 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Fri Nov 14 11:11:48 2008 Subject: [Haskell-cafe] Calling Haskell from other languages? In-Reply-To: (Colin Paul Adams's message of "Fri\, 14 Nov 2008 08\:11\:21 +0000") References: <457DB857-8E23-4DF3-964E-D54183B732EA@pikewerks.com> <1226428505.12478.3.camel@derek-laptop> <20081111193106.GA23562@hustlerturf.com> <20081114080610.GB8133@scytale.galois.com> Message-ID: >>>>> "Colin" == Colin Paul Adams writes: >>>>> "Don" == Don Stewart writes: Don> Not linking in the 'Safe' module on the command line? Colin> Could be - I don't know any of this stuff. I was just Colin> following the instructions on the wiki page. Got it working now. It seemed to be some case dependency on the file name. -- Colin Adams Preston Lancashire From andrewcoppin at btinternet.com Fri Nov 14 15:13:01 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri Nov 14 15:07:20 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <625b74080811131306x1bbc8bfdg42fac7601021c552@mail.gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <491A3953.7090305@freegeek.org> <4e7aa0f80811111941k32f80909ld7cec678d6a1b8a8@mail.gmail.com> <625b74080811131058x30a6ca1dx94d232190cef4a1c@mail.gmail.com> <491C7B3A.1060804@btinternet.com> <625b74080811131306x1bbc8bfdg42fac7601021c552@mail.gmail.com> Message-ID: <491DDBCD.9040308@btinternet.com> Dan Piponi wrote: > On Thu, Nov 13, 2008 at 11:08 AM, Andrew Coppin > wrote: > >> In other words, Haskell is an excellent language for designing >> special-purpose compilers and interpretters for custom languages. ;-) >> >> If I knew a damned thing about IA32 assembly and dynamic linkage, I'd be >> tempted to try it myself... >> > > You could generate assembly language instructions directly. Yeah. I figure if I knew enough about this stuff, I could poke code numbers directly into RAM representing the opcodes of the machine instructions. Then I "only" need to figure out how to call it from Haskell. It all sounds pretty non-trivial if you ask me though... ;-) [Don't some OS versions implement execution-prevention? Presumably you'd also have to bypass that in some platform-dependent way too...] > But if you > use the Haskell LLVM bindings your generated code will be (1) platform > independent and (2) optimised. I think there's a cool project lurking > there. > Never heard of LLVM, but from the Wikipedia description it sound like warm trippy goodness. Pitty there's no Haddock. :-( [From the build log, it looks like it failed because the build machine doesn't have the LLVM library installed. Is that really necessary just for building the docs?] From mad.one at gmail.com Fri Nov 14 15:27:29 2008 From: mad.one at gmail.com (Austin Seipp) Date: Fri Nov 14 15:21:51 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <491DDBCD.9040308@btinternet.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <491A3953.7090305@freegeek.org> <4e7aa0f80811111941k32f80909ld7cec678d6a1b8a8@mail.gmail.com> <625b74080811131058x30a6ca1dx94d232190cef4a1c@mail.gmail.com> <491C7B3A.1060804@btinternet.com> <625b74080811131306x1bbc8bfdg42fac7601021c552@mail.gmail.com> <491DDBCD.9040308@btinternet.com> Message-ID: <1226694054-sup-2918@existential.local> Excerpts from Andrew Coppin's message of Fri Nov 14 14:13:01 -0600 2008: > Yeah. I figure if I knew enough about this stuff, I could poke code > numbers directly into RAM representing the opcodes of the machine > instructions. Then I "only" need to figure out how to call it from > Haskell. It all sounds pretty non-trivial if you ask me though... ;-) Save yourself some time: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/harpy Using harpy, you can generate x86 assembly /inside/ your code and execute it, using a DSL. This makes it excellent for code generators and playing around with code generation. Here's a calculator I wrote using it: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/calc For more information, http://uebb.cs.tu-berlin.de/harpy/ > Never heard of LLVM, but from the Wikipedia description it sound like > warm trippy goodness. Pitty there's no Haddock. :-( It's a pretty excellent little system, to be honest. One of the cleanest APIs I've ever used, too (especially for C++.) > [From the build log, it looks like it failed because the build machine > doesn't have the LLVM library installed. Is that really necessary just > for building the docs?] It's necessary to even get through the 'cabal configure' step, since the configure script bundled with the haskell llvm bindings is run then, which checks for the llvm-c headers. Austin. From vigalchin at gmail.com Fri Nov 14 16:36:34 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri Nov 14 16:30:54 2008 Subject: [Haskell-cafe] Haskell library support Message-ID: <5ae4f2ba0811141336r26b4e39h79b7076bbbcdee5e@mail.gmail.com> Hello, I am looking for something to work on. Where are there perceived holes in the Haskell library support? Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081114/c13fdeff/attachment.htm From analytic at gmail.com Fri Nov 14 20:13:14 2008 From: analytic at gmail.com (Stephen) Date: Fri Nov 14 20:07:33 2008 Subject: [Haskell-cafe] Re: Haskell-Cafe Digest, Vol 63, Issue 23 In-Reply-To: <9979e72e0811140749q711ad5d6he9d1fb17b802ea27@mail.gmail.com> References: <20081114103934.EFFA93246AB@www.haskell.org> <9979e72e0811140749q711ad5d6he9d1fb17b802ea27@mail.gmail.com> Message-ID: Those suggestions are interesting, though somewhat intimidating. Having failed, subsequent to my initial message, to get sdl_mixer to work, I finally got some potentially cross-platform audio output working on my Mac by wrapping FMOD in some C code and linking appropriately. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081115/896a282a/attachment.htm From niklas.broberg at gmail.com Fri Nov 14 20:26:45 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Fri Nov 14 20:21:07 2008 Subject: [Haskell-cafe] ANNOUNCE: haskell-src-exts 0.4.1 Message-ID: Fellow Haskelleers, it is my pleasure to announce the new release of the haskell-src-exts package, version 0.4.1: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.4.1 darcs get http://code.haskell.org/HSP/haskell-src-exts This is a new "major" release, the first of the 0.4 branch, and as such it is not backwards compatible with the releases in the 0.3 branch. This is due to two major changes to the design of the library: 1) The AST has been cleaned up, by splitting Haskell expressions in the AST from the "expressions" used while parsing to represent both expressions and patterns. This means that the datatype for expressions will no longer contain constructors for things like wildcards and irrefutable patterns. It now only contains constructors for actual Haskell expressions. If you have been using haskell-src-exts previously, this change should not bite you at all unless you have abused these ugly hacks in the AST, so it is *almost* backwards compatible. However... 2) ... I've finally decided to take the plunge and get rid of the ugly prefixes on all datatypes in the AST. I am of the firm conviction that disambiguation between datatypes and functions with the same name should be handled through the module hierarchy and qualified imports, not by adding prefixes. And the longer I wait, the harder the switch. So now the datatypes that make up the AST are called things like Exp, Pat, Module (the former Module is now ModuleName), Type, QOp etc instead of HsExp, HsPat... . The migration from 0.3.x to 0.4.1 should be really simple: i) replace all occurences of Module with ModuleName ii) remove all occurences of Hs This release also contains a number of smaller, fully backwards compatible bug fixes. These are available for the 0.3 branch in the 0.3.12 release that will mark the end of that branch: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.12 No further bug fixes or features will be implemented for it, and I urge you to migrate as early as possible, it really isn't hard. :-) Cheers and Happy Haskelling, /Niklas From korcan_h at hotmail.com Fri Nov 14 21:19:11 2008 From: korcan_h at hotmail.com (Korcan Hussein) Date: Fri Nov 14 21:13:32 2008 Subject: [Haskell-cafe] HSDL 0.5.4 on GHC 6.10.1 Message-ID: Hi the package at hackage fails to build on GHC 6.10.1 (on windows mingw) this is due to 2 reasons: 1. I believe the order of libraries to be linked needs to change from "-lmingw32 -lSDLmain -lSDL" to "-lSDLmain -lSDL -lmingw32" otherwise you get linker errors which multiple definitions of main. I think the build system should output `sdl-config --cflags --libs` instead of explicitly stating which libraries besides. 2. For some reason the the library & include paths plus the list of which libraries to be linked gets appened to the output twice and thus causing linker errors. I'm a casual user of haskell so I don't much about cabal packages so I manged to figure out a hackish workaround by deleting the entry in the SDL.buildinfo file (the entry for the ld-options). _________________________________________________________________ Win ?1000 John Lewis shopping sprees with BigSnapSearch.com http://clk.atdmt.com/UKM/go/117442309/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081115/0d474e0b/attachment.htm From gour at mail.inet.hr Sat Nov 15 01:54:51 2008 From: gour at mail.inet.hr (Gour) Date: Sat Nov 15 01:49:19 2008 Subject: [Haskell-cafe] Re: Haskell library support References: <5ae4f2ba0811141336r26b4e39h79b7076bbbcdee5e@mail.gmail.com> Message-ID: <878wrlo4w4.fsf@gaura-nitai.no-ip.org> >>>>> "Galchin" == Galchin, Vasili writes: Galchin> Hello, I am looking for something to work on. Where are there Galchin> perceived holes in the Haskell library support? Do you have need to make your Haskell applications i18n-aware by using 'standard' gettext support? 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/20081115/fb9e3dd5/attachment.bin From hpacheco at gmail.com Sat Nov 15 05:07:28 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Sat Nov 15 05:01:48 2008 Subject: [Haskell-cafe] GHC 6.10 and scoped variables Message-ID: <7b92c2840811150207h27f73d05ne70380508b02aa16@mail.gmail.com> Hi, When migrating some code with type families to GHC 6.10, I frequently get the same error. The deal is. If I define some type family and instance: *type family Rep (f :: * -> *) x :: * data (g :+: h) x = Inl (g x) | Inr (h x) type instance Rep (g :+: h) x = Rep g x `Either` Rep h x* and then define a function that has a scoped argument: *test :: Rep (g :+: h) x -> y test (Left x :: Rep (g :+: h) x) = undefined* I get the error: * Pattern signature must exactly match: Rep (g :+: h) x In the pattern: Left x :: Rep (g :+: h) x In the definition of `test': test (Left x :: Rep (g :+: h) x) = undefined* Is this error expected? At least the error message is not clear... Interestingly, when experimenting with a different functor, I get the impossible: * newtype Const t x = Const {unConst :: t} type instance Rep (Const t) x = t** **test2 :: Rep (Const t) x -> y test2 x = undefined* *ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): readFilledBox x{tv aoB} [box] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > * Sorry for the extensiveness. Thanks, hugo -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081115/0ebaaa60/attachment.htm From tphyahoo at gmail.com Sat Nov 15 06:02:12 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Sat Nov 15 05:56:31 2008 Subject: [Haskell-cafe] cabal install HaXml installs wrong version unless I specify the version number Message-ID: <910ddf450811150302s3f8583baxe561a50856e2a337@mail.gmail.com> I was upgrading happstutorial.com to ghc 6.10.1 when I came across a cabal install issue. Somewhere in day 1 (probably as a HAppS dependency), HaXml 1.13.1 got installed. On day 2, I wanted the latest version of HaXml (1.19.4), a dependency for for xml-parsec. cabal install HaXml gave me: already installed. cabal upgrade HaXml gave me: some installing action, but in the end I wound up with 1.13.1 again. cabal install HaXml-1.19.4 gave me what I want, the latest version. But even then, when I do cabal install xml-parsec I get Text/ParserCombinators/Parsec/XML.hs:18:7: Could not find module `Text.XML.HaXml.Posn': it is a member of package HaXml-1.19.4, which is hidden The cabal file has Build-Depends: base, parsec, HaXml >ghc-pkg latest HaXml says HaXml-1.19.4 Even after ghc-pkg hide HaXml-1.13.3 I get the same result, so I'm not even sure if the problems I'm having are a result of the having two versions of the same package installed. This is a bug right? Any advice on how to get xml-parsec installed? thomas. From tphyahoo at gmail.com Sat Nov 15 06:10:14 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Sat Nov 15 06:04:32 2008 Subject: [Haskell-cafe] What *not* to use Haskell for In-Reply-To: <491A3953.7090305@freegeek.org> References: <1226399902.6496.9.camel@rubix.office.last.fm> <491A3953.7090305@freegeek.org> Message-ID: <910ddf450811150310g1a8ea86ck7acf84d5f1dcf05e@mail.gmail.com> I've been using HSH with good results for sysadmin tasks, and recently uploaded HSHHelpers to hackage. Of course with Cpan a lot of stuff has already been done for you, but that's a library issue. Nothing beats bash for a quicky of course, but there a lot of ways to shoot yourself in the foot (eg global variables, hard to remember quoting rules) that haskell protects me from. Like perl protects you, but better. thomas. 2008/11/12 wren ng thornton : > Dave Tapley wrote: >> >> Hi everyone >> >> So I should clarify I'm not a troll and do "see the Haskell light". But >> one thing I can never answer when preaching to others is "what does >> Haskell not do well?" >> >> Usually I'll avoid then question and explain that it is a 'complete' >> language and we do have more than enough libraries to make it useful and >> productive. But I'd be keen to know if people have any anecdotes, >> ideally ones which can subsequently be twisted into an argument for >> Haskell ;) > > With the appropriate caveats about particular subdomains (see final > paragraph), I wouldn't use Haskell for scripting. That is, (1) for > Bash-style programming where 95% of the code is just invoking *nix jobs, or > (2) for very simple yet regex-heavy scripts where Perl/Awk/Sed is often > used. > > Re #1: Honestly, I don't see anything other than a dedicated competitor > being able to unseat Bourne/Bash at this task. Certainly a competitor would > have much room for improvement-- what with being able to replace > string-rewriting semantics with term-rewriting semantics, vastly improving > type safety and catching innumerable bugs. However, with unsavory frequency, > it is exactly those type-unsafe substitutions which can make shell scripting > cleaner and more direct than a type-safe alternative. Having type safety as > well as this sort of non-compositional structure would take a good deal of > work to get right. > > Re #2: People often complain about spooky Perl that uses things like > implicit $_ or other hidden variables. While these constructs can make any > sizable project unmaintainable, for the quick and dirty jobs they're just > what's needed to get things done with clarity. While ByteString code using > regexes is just as fast in Haskell, it's often more than twice as long as > the Perl, Sed, or Awk equivalents because many of the basic control > structures (like Perl's -n, -p, -l,... flags) aren't already provided. > > > That said, this isn't necessarily a bad thing for Haskell. "Real" > programming languages often don't do so well in these areas (Perl being the > exception), and they don't feel too bad about it. Both varieties of shell > scripting are very much of the DSL nature; for programs with a significant > amount of "actual logic" instead of mere plumbing or regexing, Haskell can > certainly outshine these competitors. On the one hand, C and friends fight > dirty and much work has been done so Haskell can join in on the bit-bashing > glory. However, shell scripting is a whole different kind of imperative muck > and very little work (that I've seen) has tried to get Haskell to jump down > in the sewers with them. > > -- > Live well, > ~wren > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From tphyahoo at gmail.com Sat Nov 15 06:39:53 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Sat Nov 15 06:34:11 2008 Subject: [Haskell-cafe] Re: cabal install HaXml installs wrong version unless I specify the version number In-Reply-To: <910ddf450811150302s3f8583baxe561a50856e2a337@mail.gmail.com> References: <910ddf450811150302s3f8583baxe561a50856e2a337@mail.gmail.com> Message-ID: <910ddf450811150339u7920683do227dceb02383634f@mail.gmail.com> When I specify Build-Depends: base, parsec, HaXml >= 1.19.4 in xml-parsec.cabal it does install correctly. I guess what happens is that cabal install takes the earliest version of a package registered to try to build. I guess that's a reasonable default. What seems unreasonable to me is that cabal continued to take the earlier version even after I hid it with ghc-pkg hide. My advice would be to improve the error message to read "... Could not find module `Text.XML.HaXml.Posn': it is a member of package HaXml-1.19.4, which is hidden It can be unhidden by adding Build-Depends: HaXml >= 1.19.4 to xml-parsec.cabal" That leaves the issue of cabal upgrade not upgrading to the latest version available on hackage, which still feels like a real bug to me. Best, Thomas. 2008/11/15 Thomas Hartman : > I was upgrading happstutorial.com to ghc 6.10.1 when I came across a > cabal install issue. > > Somewhere in day 1 (probably as a HAppS dependency), HaXml 1.13.1 got installed. > > On day 2, I wanted the latest version of HaXml (1.19.4), a dependency > for for xml-parsec. > > cabal install HaXml gave me: already installed. > cabal upgrade HaXml gave me: some installing action, but in the end I > wound up with 1.13.1 again. > > cabal install HaXml-1.19.4 gave me what I want, the latest version. > > But even then, when I do cabal install xml-parsec I get > > Text/ParserCombinators/Parsec/XML.hs:18:7: > Could not find module `Text.XML.HaXml.Posn': > it is a member of package HaXml-1.19.4, which is hidden > > The cabal file has > > Build-Depends: base, parsec, HaXml > >>ghc-pkg latest HaXml says > HaXml-1.19.4 > > Even after ghc-pkg hide HaXml-1.13.3 > > I get the same result, so I'm not even sure if the problems I'm having > are a result of the having two versions of the same package installed. > > This is a bug right? > > Any advice on how to get xml-parsec installed? > > thomas. > From duncan.coutts at worc.ox.ac.uk Sat Nov 15 07:02:58 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Nov 15 06:57:20 2008 Subject: [Haskell-cafe] Re: cabal install HaXml installs wrong version unless I specify the version number In-Reply-To: <910ddf450811150339u7920683do227dceb02383634f@mail.gmail.com> References: <910ddf450811150302s3f8583baxe561a50856e2a337@mail.gmail.com> <910ddf450811150339u7920683do227dceb02383634f@mail.gmail.com> Message-ID: <1226750578.15832.12.camel@localhost> On Sat, 2008-11-15 at 12:39 +0100, Thomas Hartman wrote: > When I specify > > Build-Depends: base, parsec, HaXml >= 1.19.4 > > in xml-parsec.cabal > > it does install correctly. Yes, saying what version it needs is a good thing. It's all guesses otherwise. > I guess what happens is that cabal install takes the earliest version > of a package registered to try to build. I guess that's a reasonable > default. Actually it does that for specific packages, there's a file in the hackage index called 'referred-versions': base < 4 parsec < 3 HaXml == 1.13.* QuickCheck < 2 These are all cases where there are large numbers of packages that fail to specify an upper version constraint but break when built with the later version of the package. In the case of HaXml it is also because the 1.13 series is the one considered stable by its author. > What seems unreasonable to me is that cabal continued to take the > earlier version even after I hid it with ghc-pkg hide. We cannot in general consider the hidden status of packages or we'd never be able to use packages like 'ghc' which are always hidden. Perhaps they could be used as soft preferences. If so should those come before or after the preferences from the command line or from the hackage index? > My advice would be to improve the error message to read > > "... Could not find module `Text.XML.HaXml.Posn': > it is a member of package HaXml-1.19.4, which is hidden > It can be unhidden by adding > > Build-Depends: HaXml >= 1.19.4 > > to xml-parsec.cabal" Unfortunately we cannot easily do that. It is ghc that produces the message about hidden packages but it is cabal that told ghc to hide all the packages (other than those specified in the .cabal file). Some people suggest that we should try parsing the ghc error messages to be able to provide such hints but I don't think that's sensible. > That leaves the issue of cabal upgrade not upgrading to the latest > version available on hackage, which still feels like a real bug to me. That's again down to the preferred versions in the hackage index. It only comes into effect when you specify no version when asking for a package. If you cabal install 'haxml >= 1.14' then it'll pick the latest version. When you "cabal install haxml", do you mean "install the default version" or "install the latest experimental version"? Currently it means the former. If there is general agreement it should mean the latter then we can switch it. Or perhaps it just needs an informational message to tell the user whenever the default version is not the latest version. cabal install haxml Downloading HaXml-1.13.3... Note: the recommended version is HaXml-1.13.3 but latest version is HaXml-1.19, use cabal install haxml-1.19 if you want that version. Or something like that. Duncan From duncan.coutts at worc.ox.ac.uk Sat Nov 15 07:10:00 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Nov 15 07:04:19 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: haskell-src-exts 0.4.1 In-Reply-To: References: Message-ID: <1226751000.15832.18.camel@localhost> On Sat, 2008-11-15 at 02:26 +0100, Niklas Broberg wrote: > Fellow Haskelleers, > > it is my pleasure to announce the new release of the haskell-src-exts > package, version 0.4.1: > 2) ... I've finally decided to take the plunge and get rid of the ugly > prefixes on all datatypes in the AST. I am of the firm conviction that > disambiguation between datatypes and functions with the same name > should be handled through the module hierarchy and qualified imports, > not by adding prefixes. Yes! > And the longer I wait, the harder the switch. So now the datatypes > that make up the AST are called things like Exp, Pat, Module (the > former Module is now ModuleName), Type, QOp etc instead of HsExp, > HsPat... . Yay! That is all. :-) Duncan From tphyahoo at gmail.com Sat Nov 15 07:31:34 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Sat Nov 15 07:25:54 2008 Subject: [Haskell-cafe] Re: cabal install HaXml installs wrong version unless I specify the version number In-Reply-To: <1226750578.15832.12.camel@localhost> References: <910ddf450811150302s3f8583baxe561a50856e2a337@mail.gmail.com> <910ddf450811150339u7920683do227dceb02383634f@mail.gmail.com> <1226750578.15832.12.camel@localhost> Message-ID: <910ddf450811150431ve395cb2gd9ade01e9d8c6a6a@mail.gmail.com> This is all news to me, and un-googleable to boot: http://www.google.pl/search?hl=en&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=cabal+referred-versions&spell=1 (no results) So yes, I think this referred-versions machinery should at least be made more transparent for situations when it does the wrong thing, like with xml-parsec. I think your last suggestion is good > cabal install haxml > Downloading HaXml-1.13.3... > Note: the recommended version is HaXml-1.13.3 but latest version is > HaXml-1.19, use cabal install haxml-1.19 if you want that version. I would have this message pop up for both cabal install and cabal upgrade -- especiallly since with cabal upgrade the result was for me completely bafflling. Thomas. 2008/11/15 Duncan Coutts : > On Sat, 2008-11-15 at 12:39 +0100, Thomas Hartman wrote: >> When I specify >> >> Build-Depends: base, parsec, HaXml >= 1.19.4 >> >> in xml-parsec.cabal >> >> it does install correctly. > > Yes, saying what version it needs is a good thing. It's all guesses > otherwise. > >> I guess what happens is that cabal install takes the earliest version >> of a package registered to try to build. I guess that's a reasonable >> default. > > Actually it does that for specific packages, there's a file in the > hackage index called 'referred-versions': > > base < 4 > parsec < 3 > HaXml == 1.13.* > QuickCheck < 2 > > These are all cases where there are large numbers of packages that fail > to specify an upper version constraint but break when built with the > later version of the package. In the case of HaXml it is also because > the 1.13 series is the one considered stable by its author. > >> What seems unreasonable to me is that cabal continued to take the >> earlier version even after I hid it with ghc-pkg hide. > > We cannot in general consider the hidden status of packages or we'd > never be able to use packages like 'ghc' which are always hidden. > Perhaps they could be used as soft preferences. If so should those come > before or after the preferences from the command line or from the > hackage index? > >> My advice would be to improve the error message to read >> >> "... Could not find module `Text.XML.HaXml.Posn': >> it is a member of package HaXml-1.19.4, which is hidden >> It can be unhidden by adding >> >> Build-Depends: HaXml >= 1.19.4 >> >> to xml-parsec.cabal" > > Unfortunately we cannot easily do that. It is ghc that produces the > message about hidden packages but it is cabal that told ghc to hide all > the packages (other than those specified in the .cabal file). Some > people suggest that we should try parsing the ghc error messages to be > able to provide such hints but I don't think that's sensible. > >> That leaves the issue of cabal upgrade not upgrading to the latest >> version available on hackage, which still feels like a real bug to me. > > That's again down to the preferred versions in the hackage index. It > only comes into effect when you specify no version when asking for a > package. If you cabal install 'haxml >= 1.14' then it'll pick the latest > version. > > When you "cabal install haxml", do you mean "install the default > version" or "install the latest experimental version"? Currently it > means the former. If there is general agreement it should mean the > latter then we can switch it. > > Or perhaps it just needs an informational message to tell the user > whenever the default version is not the latest version. > > cabal install haxml > Downloading HaXml-1.13.3... > Note: the recommended version is HaXml-1.13.3 but latest version is > HaXml-1.19, use cabal install haxml-1.19 if you want that version. > > Or something like that. > > Duncan > > From ndmitchell at gmail.com Sat Nov 15 07:57:02 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Nov 15 07:51:21 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: haskell-src-exts 0.4.1 In-Reply-To: <1226751000.15832.18.camel@localhost> References: <1226751000.15832.18.camel@localhost> Message-ID: <404396ef0811150457r41646efan715126acceaefbfa@mail.gmail.com> >> Fellow Haskelleers, >> >> it is my pleasure to announce the new release of the haskell-src-exts >> package, version 0.4.1: All looks great :-) I upgraded my project using HSE, which made very heavy use of the library, in about 15 minutes. And that included getting name 3 clashes and fixing one abuse of HsWildcard :-) Any chance of including support for view patterns in a future release? http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#view-patterns . The project I'm writing using HSE makes significant use of view patterns, and it would be lovely if I could be self applicable :-) Thanks Neil From deduktionstheorem at web.de Sat Nov 15 08:28:50 2008 From: deduktionstheorem at web.de (Stephan Friedrichs) Date: Sat Nov 15 08:23:13 2008 Subject: [Haskell-cafe] Re: cabal install HaXml installs wrong version unless I specify the version number In-Reply-To: <910ddf450811150339u7920683do227dceb02383634f@mail.gmail.com> References: <910ddf450811150302s3f8583baxe561a50856e2a337@mail.gmail.com> <910ddf450811150339u7920683do227dceb02383634f@mail.gmail.com> Message-ID: <491ECE92.5010209@web.de> Thomas Hartman wrote: > When I specify > > Build-Depends: base, parsec, HaXml >= 1.19.4 > > in xml-parsec.cabal > > it does install correctly. I just fixed xml-parsec.cabal and uploaded it on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml-parsec-1.0.3 > > [...] > //Stephan -- Fr?her hie? es ja: Ich denke, also bin ich. Heute wei? man: Es geht auch so. - Dieter Nuhr From duncan.coutts at worc.ox.ac.uk Sat Nov 15 08:39:18 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Nov 15 08:33:38 2008 Subject: [Haskell-cafe] Re: cabal install HaXml installs wrong version unless I specify the version number In-Reply-To: <910ddf450811150431ve395cb2gd9ade01e9d8c6a6a@mail.gmail.com> References: <910ddf450811150302s3f8583baxe561a50856e2a337@mail.gmail.com> <910ddf450811150339u7920683do227dceb02383634f@mail.gmail.com> <1226750578.15832.12.camel@localhost> <910ddf450811150431ve395cb2gd9ade01e9d8c6a6a@mail.gmail.com> Message-ID: <1226756358.15832.25.camel@localhost> On Sat, 2008-11-15 at 13:31 +0100, Thomas Hartman wrote: > This is all news to me, and un-googleable to boot: > > http://www.google.pl/search?hl=en&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=cabal+referred-versions&spell=1 > > (no results) It finds something for me (with the right spelling of preferred), eg this thread from the libraries list: http://archive.netbsd.se/?ml=haskell-libraries&a=2008-10&t=8748731 > So yes, I think this referred-versions machinery should at least be > made more transparent for situations when it does the wrong thing, > like with xml-parsec. Sure, though it is worth remembering that doing the right thing for xml-parsec is completely a guessing game since the package does not say which version it needs and yet works with some versions and not others. That is the root of this problem. We should be thinking about ways to persuade package authors (or others) to supply the correct information. That's where the package versioning policy comes in. > I think your last suggestion is good > > > cabal install haxml > > Downloading HaXml-1.13.3... > > Note: the recommended version is HaXml-1.13.3 but latest version is > > HaXml-1.19, use cabal install haxml-1.19 if you want that version. > > I would have this message pop up for both cabal install and cabal > upgrade -- especiallly since with cabal upgrade the result was for me > completely bafflling. Ok, so that we do not forget this, would you mind filing a ticket to explain the confusion and the suggested solution. Linking to this thread would also help. http://hackage.haskell.org/trac/hackage/ Duncan From niklas.broberg at gmail.com Sat Nov 15 08:59:43 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sat Nov 15 08:54:01 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: haskell-src-exts 0.4.1 In-Reply-To: <404396ef0811150457r41646efan715126acceaefbfa@mail.gmail.com> References: <1226751000.15832.18.camel@localhost> <404396ef0811150457r41646efan715126acceaefbfa@mail.gmail.com> Message-ID: > Any chance of including support for view patterns in a future release? > http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#view-patterns > . The project I'm writing using HSE makes significant use of view > patterns, and it would be lovely if I could be self applicable :-) Chance, definitely. In the perfect world, HSE would support everything that any Haskell compiler supports, so you might say I "plan" to include every extension, it's just a question of time and priority. And getting explicit requests for a particular feature certainly increases the latter. (Oh how I wish it would increase the former too...) :-) Cheers, /Niklas From dons at galois.com Sat Nov 15 15:28:36 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 15 15:22:53 2008 Subject: [Haskell-cafe] Re: cabal install HaXml installs wrong version unless I specify the version number In-Reply-To: <491ECE92.5010209@web.de> References: <910ddf450811150302s3f8583baxe561a50856e2a337@mail.gmail.com> <910ddf450811150339u7920683do227dceb02383634f@mail.gmail.com> <491ECE92.5010209@web.de> Message-ID: <20081115202836.GO15077@scytale.galois.com> deduktionstheorem: > Thomas Hartman wrote: > > When I specify > > > > Build-Depends: base, parsec, HaXml >= 1.19.4 > > > > in xml-parsec.cabal > > > > it does install correctly. > > I just fixed xml-parsec.cabal and uploaded it on hackage: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml-parsec-1.0.3 Note that packages that depend on the 'experimental' versions of things (in particular Haxml 1.19.* can't be packaged for Arch either, as we can only install one version of the haskell-haxml package). -- Don From briqueabraque at yahoo.com Sat Nov 15 15:29:23 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Sat Nov 15 15:23:51 2008 Subject: [Haskell-cafe] Begginer question about alignment in Storable Message-ID: Hi, I need to make the following structure into an instance of Storable: struct { double w[2]; } Can I assume that its function 'alignment' should return the same as "alignment (1::CDouble)"? Or should it be "2 * alignment (1::CDouble)"? (I've read the wikipedia article about memory alignment, and what I understand is that there's a better alignment for hardware efficiency but compilers and programmers can do almost anything about it. What can I do when writing a library wrapper if I don't know what kind of compiler pragmas were used in all platforms that library was compiled?) Thanks, Maur?cio From byorgey at seas.upenn.edu Sat Nov 15 15:55:52 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Nov 15 15:50:10 2008 Subject: [Haskell-cafe] Haskell Weekly News: Issue 93 - November 15, 2008 Message-ID: <20081115205552.GA15664@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20081115 Issue 93 - November 15, 2008 --------------------------------------------------------------------------- Welcome to issue 93 of HWN, a newsletter covering developments in the [1]Haskell community. Community News Congratulations to Ganesh (aka Heffalump) and Amanda on the [2]birth of Alexander Suresh Kerr Sittampalam! Announcements bustle-0.1. Will Thompson [3]announced the [4]release of [5]Bustle, a tool to show diagrams of D-Bus traffic for profiling purposes. It consists of a small C executable to log traffic, and a Gtk+ application which draws diagrams using Cairo. haskell-src-exts 0.4.1. Niklas Broberg [6]announced a new major release of the [7]haskell-src-exts package, an extension of the standard haskell-src package which handles most common syntactic extensions to Haskell. The new release features a cleaned up AST and names without ugly disambiguation prefixes. darcs 2.1.1rc2. Eric Kow (kowey) [8]announced the release of [9]darcs 2.1.1rc2, which adds support for GHC 6.10.1. It also includes a Windows bug fix. If you're using GHC 6.10.1 or Windows, give it a try and let the darcs development team know how it works. hpapi 0.1 release. Michael D. Adams [10]announced the first release of [11]hpapi, Performance API (PAPI) bindings for Haskell. PAPI provides access to various CPU counters such as cache-miss, instruction and pipeline stall counts. Workflow-0.1. Alberto G. Corona [12]announced the release of [13]Workflow, a library for transparent execution of computations across shutdowns and restarts. Reactive library (FRP) and mailing list. Conal Elliott [14]announced the release of [15]Reactive, a library for functional reactive programming (FRP), similar to the original [16]Fran but with a more modern interface (using standard type classes) and a hybrid push/pull implementation. It is designed to be used in a variety of contexts, such as interactive 2D and 3D graphics, graphical user interfaces, web services, and automatic recompilation/re-execution. There is also now a [17]mailing list and a [18]feature/bug tracker. ANN (sorta): OpenGL with extra type safety. Neal Alexander [19]announced a modification of the hOpenGL (and GLFW) source tree to force extra type checking on its various IO actions using the -XGeneralizedNewtypeDeriving extension. The main motivation was for writing concurrent OpenGL applications; the second motivation was to enforce static type checking on commands that can only be executed in certain OpenGL contexts (sending vertex data for example). Hopefully the code will be uploaded to Hackage as a separate package soon. FieldTrip library (functional 3D) and mailing list. Conal Elliott [20]announced the release of [21]FieldTrip, a library for functional 3D graphics. It is intended for building static, animated, and interactive 3D geometry, efficient enough for real-time synthesis and display. FieldTrip also has a [22]mailing list and a [23]feature/bug tracker. gitit 0.2 release - wiki using HAppS, git, pandoc. John MacFarlane [24]announced the upload of an early version of [25]gitit, a Haskell wiki program, to HackageDB. Gitit uses HAppS as a webserver, git for file storage, pandoc for rendering the (markdown) pages, and highlighting-kate for highlighted source code. You can [26]try it out here. Comments and patches welcome. Discussion Proof that Haskell is RT. Andrew Birkett [27]asked whether there exists a formal proof that the Haskell language is referentially transparent. Such a thing cannot exist, since Haskell has no formally defined semantics, but an interesting discussion about referential transparency and semantics ensued anyway. What *not* to use Haskell for. Dave Tapley [28]asked how people answer the question, "what does Haskell not do well?" Unfortunately, it seems that there is no good answer to this question and the thread degenerated into a discussion of all the great things you can do with Haskell. If only Haskell sucked more. Blog noise [29]Haskell news from the [30]blogosphere. * Braden Shepherdson: [31]Pimp Your XMonad #2: SmartBorders. The second in Braden's series on customising xmonad explains how to use the NoBorders extension to get rid of window borders when you don't want them. * Real-World Haskell: [32]Real World Haskell Electronic Edition Now On Sale. * Conal Elliott: [33]More beautiful fold zipping. * >>> Stephen: [34]Endless Cavern. A procedurally-generated tessellated-cavern flying game. * Twan van Laarhoven: [35]Arrays without bounds. Unbounded arrays (with O(1) amortized access) in Haskell! * "The GHC Team": [36]Comparing concurrent linked-list implementations in Haskell. * Ketil Malde: [37]454 sequencing and parsing the SFF binary format. * Tom Schrijvers: [38]Type Invariants for Haskell. Tom, Louis-Julien Guillemette, and Stefan Monnier's paper on Type Invariants for Haskell, which was recently accepted at PLPV'09. * Conal Elliott: [39]Another lovely example of type class morphisms. Conal elaborates on Max Rabkin's recent post on composable folds. * Real-World Haskell: [40]Beautiful Parallelism: Harnessing Multicores with Haskell. Don Stewart will be talking about programming mainstream multicore systems with Haskell at SC'08 next week in Austin, Texas. * Luke Palmer: [41]Sketch of Udon (Version Control/Packaging system). Luke sketches a high-level design for a distributed storage system that could be used as the basis for solving a number of interesting problems. * Galois, Inc: [42]Galois awarded NASA research contract. * Mark Jason Dominus: [43]Representing ordinal numbers in the computer and elsewhere. * The GHC Team: [44]Bootstrapping cabal-install. * Jason Dagit: [45]Phantom Types, Existentials and Controlling Unification -- Part 1. * Ben Moseley: [46]Why does Functional Programming matter?. Quotes of the Week * BMeph: In a functional world, students would ask how that index shadowing works in those funny 'for' statements... * digit: i'm almost annoyed at how brilliant xmonad is. * _pizza_: i think Haskell is undoubtedly the world's best programming language for discovering the first few dozen numbers in the Fibonacci sequence over IRC. * adu: let uncat3 [] = [] ; uncat3 xs = (let (ys, zs) = splitAt 3 xs in ys : uncat3 zs) ; getFrom x y = map (x !!) $ map (fromIntegral . ((\x -> fromIntegral $ foldl (.|.) (0::Word8) (zipWith (\c n -> if c then bit n else (0::Word8)) x [0..2])) :: [Bool] -> Int)) $ reverse . uncat3 . reverse . concat . map (((\x -> map (testBit x) [7,6..0]) :: Word8 -> [Bool]) . fromIntegral . ord) $ y in getFrom " HWdelor" "e\184-\235" * Beelsebob: ((:[]) "pigs eat") <^(++)^> ((:[]) " robot monkies") About the Haskell Weekly News New editions are posted to [47]the Haskell mailing list as well as to [48]the Haskell Sequence and [49]Planet Haskell. [50]RSS is also available, and headlines appear on [51]haskell.org. To help create new editions of this newsletter, please see the information on [52]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [53]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://urchin.earth.li/aegean/baby/ 3. http://www.haskell.org//pipermail/haskell-cafe/2008-November/050626.html 4. http://people.collabora.co.uk/~wjt/bustle/releases/bustle-0.1.tar.gz 5. http://resiak.livejournal.com/59590.html 6. http://www.haskell.org//pipermail/haskell-cafe/2008-November/050634.html 7. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.4.1 8. http://www.haskell.org//pipermail/haskell-cafe/2008-November/050378.html 9. http://darcs.net/darcs-2.1.1rc2.tar.gz 10. http://article.gmane.org/gmane.comp.lang.haskell.general/16612 11. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hpapi 12. http://article.gmane.org/gmane.comp.lang.haskell.general/16607 13. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Workflow 14. http://article.gmane.org/gmane.comp.lang.haskell.general/16604 15. http://haskell.org/haskellwiki/Reactive 16. http://conal.net/Fran 17. http://www.haskell.org/mailman/listinfo/reactive 18. http://trac.haskell.org/reactive 19. http://article.gmane.org/gmane.comp.lang.haskell.cafe/47458 20. http://article.gmane.org/gmane.comp.lang.haskell.cafe/47416 21. http://haskell.org/haskellwiki/FieldTrip 22. http://www.haskell.org/mailman/listinfo/FieldTrip 23. http://trac.haskell.org/FieldTrip 24. http://article.gmane.org/gmane.comp.lang.haskell.cafe/47384 25. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/gitit 26. http://johnmacfarlane.net:5001/ 27. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/47569 28. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/47491 29. http://planet.haskell.org/ 30. http://haskell.org/haskellwiki/Blog_articles 31. http://braincrater.wordpress.com/2008/11/15/pimp-your-xmonad-2-smartborders/ 32. http://www.realworldhaskell.org/blog/2008/11/15/real-world-haskell-electronic-edition-now-on-sale/ 33. http://feeds.feedburner.com/~r/conal/~3/453765396/ 34. http://www.maths.tcd.ie/~icecube/2008/11/endless-cavern/ 35. http://twan.home.fmf.nl/blog/haskell/UnboundedArray.details 36. http://ghcmutterings.wordpress.com/2008/11/14/comparing-concurrent-linked-list-implementations-in-haskell/ 37. http://blog.malde.org/index.php/2008/11/14/454-sequencing-and-parsing-the-sff-binary-format/ 38. http://tomschrijvers.blogspot.com/2008/11/type-invariants-for-haskell.html 39. http://feeds.feedburner.com/~r/conal/~3/452607365/ 40. http://www.realworldhaskell.org/blog/2008/11/12/beautiful-parallelism-harnessing-multicores-with-haskell/ 41. http://lukepalmer.wordpress.com/2008/11/12/sketch-of-udon-version-controlpackaging-system/ 42. http://www.galois.com/blog/2008/11/11/galois-awarded-nasa-research-contract/ 43. http://blog.plover.com/math/ordinals.html 44. http://ghcmutterings.wordpress.com/2008/11/10/bootstrapping-cabal-install/ 45. http://blog.codersbase.com/2008/11/10/phantom-types-existentials-and-controlling-unification-part-1/ 46. http://nattermorphisms.blogspot.com/2008/11/why-does-functional-programming-matter.html 47. http://www.haskell.org/mailman/listinfo/haskell 48. http://sequence.complete.org/ 49. http://planet.haskell.org/ 50. http://sequence.complete.org/node/feed 51. http://haskell.org/ 52. http://haskell.org/haskellwiki/HWN 53. http://code.haskell.org/~byorgey/code/hwn/ From bulat.ziganshin at gmail.com Sat Nov 15 16:18:01 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Nov 15 16:12:27 2008 Subject: [Haskell-cafe] Begginer question about alignment in Storable In-Reply-To: References: Message-ID: <191141816.20081116001801@gmail.com> Hello Maur??cio, Saturday, November 15, 2008, 11:29:23 PM, you wrote: > struct { > double w[2]; > } > Can I assume that its function 'alignment' should > return the same as "alignment (1::CDouble)"? Or > should it be "2 * alignment (1::CDouble)"? secind - definitely not. first - probably yes -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From mdmkolbe at gmail.com Sat Nov 15 16:47:02 2008 From: mdmkolbe at gmail.com (Michael D. Adams) Date: Sat Nov 15 16:41:19 2008 Subject: [Haskell-cafe] Begginer question about alignment in Storable In-Reply-To: References: Message-ID: If you are using hsc2hs (if you are using Cabal this is easy; just rename the file to *.hsc and Cabal will take care of the rest), then there is a macro for making this easier and so you don't have to think about it. First, place the following at the top of your source file: #let alignment t = "%lu", (unsigned long)offsetof(struct {char x__; t (y__); }, y__) Then #{alignment c_type} will always be expanded by hsc2hs to the correct alignment for the C type named c_type. On Sat, Nov 15, 2008 at 3:29 PM, Maur??cio wrote: > Hi, > > I need to make the following structure into > an instance of Storable: > > struct { > double w[2]; > } > > Can I assume that its function 'alignment' should > return the same as "alignment (1::CDouble)"? Or > should it be "2 * alignment (1::CDouble)"? > > (I've read the wikipedia article about memory alignment, > and what I understand is that there's a better alignment > for hardware efficiency but compilers and programmers can > do almost anything about it. What can I do when writing > a library wrapper if I don't know what kind of compiler > pragmas were used in all platforms that library was > compiled?) > > Thanks, > Maur?cio > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dagit at codersbase.com Sat Nov 15 17:06:03 2008 From: dagit at codersbase.com (Jason Dagit) Date: Sat Nov 15 17:00:21 2008 Subject: [Haskell-cafe] Find unused exports Message-ID: Hello, Has anyone already made a tool to check if exported functions, data constructors, types, etc are unused within a set of modules? For my usage it would probably suffice if the tool only compared import lists against export lists as we compile with -Wall and 99% of our imports say exactly which names are imported (and that last 1% could easily be fixed to say as well). If the tool doesn't already exist is there an easy way to approximate it? Thanks, Jason From dons at galois.com Sat Nov 15 17:16:39 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 15 17:10:55 2008 Subject: [Haskell-cafe] Find unused exports In-Reply-To: References: Message-ID: <20081115221639.GV15077@scytale.galois.com> dagit: > Hello, > > Has anyone already made a tool to check if exported functions, data > constructors, types, etc are unused within a set of modules? > > For my usage it would probably suffice if the tool only compared > import lists against export lists as we compile with -Wall and 99% of > our imports say exactly which names are imported (and that last 1% > could easily be fixed to say as well). > > If the tool doesn't already exist is there an easy way to approximate it? Have you used the minimal imports flag? That might hint at what /exports/ can also be removed. -- Don From valgarv at gmx.net Sat Nov 15 17:59:09 2008 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Sat Nov 15 17:53:30 2008 Subject: [Haskell-cafe] Good name for this operator? Message-ID: <1226789949.11259.14.camel@lnx-arielb> Hi all! When working with Applicative, I often find myself defining and using this operator: (<%>) :: (Applicative f) => f (a -> b) -> a -> f b f <%> x = f <*> pure x and always keep wondering whether it is already known by another name. Can't find it in Control.Applicative. Hoogle didn't give me much either. NB: In general, there's a weird obstacle I notice when writing Haskell: the unshakable feeling that whatever I write, there's already a better name for it and a more elegant implementation lying around. It can get downright paralyzing at times *shudder* Have Fun, -- Ariel J. Birnbaum From lrpalmer at gmail.com Sat Nov 15 18:23:08 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sat Nov 15 18:17:24 2008 Subject: [Haskell-cafe] Good name for this operator? In-Reply-To: <1226789949.11259.14.camel@lnx-arielb> References: <1226789949.11259.14.camel@lnx-arielb> Message-ID: <7ca3f0160811151523m49325bd3tfb872d8c2bc5c5ca@mail.gmail.com> On Sat, Nov 15, 2008 at 3:59 PM, Ariel J. Birnbaum wrote: > Hi all! > > When working with Applicative, I often find myself defining and using > this operator: > > (<%>) :: (Applicative f) => f (a -> b) -> a -> f b > f <%> x = f <*> pure x Yeah, me too. The syntax chosen for applicative does not encode all the information about the lifting of each side. For example, as far as I can tell, <$> is appropriate for both this and for fmap. So I think <%> is a fine name (I often use % as the application operator when I'm encoding lambda calculus). Luke From niklas.broberg at gmail.com Sat Nov 15 18:24:38 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sat Nov 15 18:18:56 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: haskell-src-exts 0.4.1 In-Reply-To: <404396ef0811150457r41646efan715126acceaefbfa@mail.gmail.com> References: <1226751000.15832.18.camel@localhost> <404396ef0811150457r41646efan715126acceaefbfa@mail.gmail.com> Message-ID: > Any chance of including support for view patterns in a future release? > http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#view-patterns > . The project I'm writing using HSE makes significant use of view > patterns, and it would be lovely if I could be self applicable :-) Fellow Haskelleers, it is my pleasure to announce the new release of the haskell-src-exts package, version 0.4.2: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.4.2 Now with view patterns. :-) Cheers, /Niklas From valgarv at gmx.net Sat Nov 15 18:29:31 2008 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Sat Nov 15 18:23:50 2008 Subject: [Haskell-cafe] Good name for this operator? In-Reply-To: <7ca3f0160811151523m49325bd3tfb872d8c2bc5c5ca@mail.gmail.com> References: <1226789949.11259.14.camel@lnx-arielb> <7ca3f0160811151523m49325bd3tfb872d8c2bc5c5ca@mail.gmail.com> Message-ID: <1226791771.11259.18.camel@lnx-arielb> On Sat, 2008-11-15 at 16:23 -0700, Luke Palmer wrote: > On Sat, Nov 15, 2008 at 3:59 PM, Ariel J. Birnbaum wrote: > > When working with Applicative, I often find myself defining and using > > this operator: > > > > (<%>) :: (Applicative f) => f (a -> b) -> a -> f b > > f <%> x = f <*> pure x > > Yeah, me too. So how does one go about asking for its inclusion in Control.Applicative? We might as well agree on a common name for it... -- Ariel J. Birnbaum From ross at soi.city.ac.uk Sat Nov 15 18:53:01 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Nov 15 18:47:20 2008 Subject: [Haskell-cafe] Good name for this operator? In-Reply-To: <1226789949.11259.14.camel@lnx-arielb> References: <1226789949.11259.14.camel@lnx-arielb> Message-ID: <20081115235301.GA11142@soi.city.ac.uk> On Sun, Nov 16, 2008 at 12:59:09AM +0200, Ariel J. Birnbaum wrote: > When working with Applicative, I often find myself defining and using > this operator: > > (<%>) :: (Applicative f) => f (a -> b) -> a -> f b > f <%> x = f <*> pure x > > and always keep wondering whether it is already known by another name. f <%> x = fmap ($ x) f will be more efficient in many cases. As for the name, <$$> would be analogous with the existing <**>. From deduktionstheorem at web.de Sun Nov 16 05:47:17 2008 From: deduktionstheorem at web.de (Stephan Friedrichs) Date: Sun Nov 16 05:41:39 2008 Subject: [Haskell-cafe] Re: cabal install HaXml installs wrong version unless I specify the version number In-Reply-To: <20081115202836.GO15077@scytale.galois.com> References: <910ddf450811150302s3f8583baxe561a50856e2a337@mail.gmail.com> <910ddf450811150339u7920683do227dceb02383634f@mail.gmail.com> <491ECE92.5010209@web.de> <20081115202836.GO15077@scytale.galois.com> Message-ID: <491FFA35.30503@web.de> Don Stewart wrote: > [...] > > Note that packages that depend on the 'experimental' versions of things > (in particular Haxml 1.19.* can't be packaged for Arch either, as we can > only install one version of the haskell-haxml package). In this case we definetely need haxml-1.19. IIRC we even committed patches to the haxml repository, when we were developing Barracuda a year ago :) //Stephan -- Fr?her hie? es ja: Ich denke, also bin ich. Heute wei? man: Es geht auch so. - Dieter Nuhr From nominolo at googlemail.com Sun Nov 16 08:35:35 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Sun Nov 16 08:29:51 2008 Subject: [Haskell-cafe] Find unused exports In-Reply-To: References: Message-ID: <916b84820811160535n494a67e7y99296053c3a55e6f@mail.gmail.com> The relevant flag is: -ddump-minimal-imports See http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id2630684 2008/11/15 Jason Dagit : > Hello, > > Has anyone already made a tool to check if exported functions, data > constructors, types, etc are unused within a set of modules? > > For my usage it would probably suffice if the tool only compared > import lists against export lists as we compile with -Wall and 99% of > our imports say exactly which names are imported (and that last 1% > could easily be fixed to say as well). > > If the tool doesn't already exist is there an easy way to approximate it? > > Thanks, > Jason > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Push the envelope. Watch it bend. From jefferson.r.heard at gmail.com Sun Nov 16 14:04:51 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Sun Nov 16 13:59:07 2008 Subject: [Haskell-cafe] HAPPS on a major hosting provider? Message-ID: <4165d3a70811161104r725ef9ddo477ccc2a65faaa4a@mail.gmail.com> I was wondering if anyone's ever tried to run Haaps on a major hosting provider, like oh, say Site5? I have an app I'd otherwise use Rails for and I thought I'd give Haaps a try... -- Jeff I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From dagit at codersbase.com Sun Nov 16 14:51:21 2008 From: dagit at codersbase.com (Jason Dagit) Date: Sun Nov 16 14:45:35 2008 Subject: [Haskell-cafe] Find unused exports In-Reply-To: <916b84820811160535n494a67e7y99296053c3a55e6f@mail.gmail.com> References: <916b84820811160535n494a67e7y99296053c3a55e6f@mail.gmail.com> Message-ID: On Sun, Nov 16, 2008 at 5:35 AM, Thomas Schilling wrote: > The relevant flag is: -ddump-minimal-imports > > See http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id2630684 The documentation says this: > -ddump-minimal-imports > > Dump to the file "M.imports" (where M is the module being compiled) a > "minimal" set of import declarations. You can safely replace all the import > declarations in "M.hs" with those found in "M.imports". Why would you want > to do that? Because the "minimal" imports (a) import everything explicitly, > by name, and (b) import nothing that is not required. It can be quite > painful to maintain this property by hand, so this flag is intended to > reduce the labour. > I already know the minimal set of import for the modules. That's why I mentioned using -Wall; ghc will complain if you import something and don't use it. The problem is that you can export names that never get used in other modules. I would like a tool that can look over a project and tell me which exported names are never imported. These names correspond to things that can be removed from the project. Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081116/2ab89811/attachment.htm From briqueabraque at yahoo.com Sun Nov 16 16:32:11 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Sun Nov 16 16:26:36 2008 Subject: [Haskell-cafe] Type question in instance of a class Message-ID: Hi, Why is this wrong? ---- class MyClass r where function :: r -> s data MyData u = MyData u instance MyClass (MyData v) where function (MyData a) = a ---- GHC says that the type of the result of 'function' is both determined by the "rigid type" from MyClass and the "rigid type" from MyData. But why can't both be the same? What am I doing wrong? Thanks for your help, Maur?cio From bulat.ziganshin at gmail.com Sun Nov 16 16:49:01 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Nov 16 16:43:37 2008 Subject: [Haskell-cafe] Type question in instance of a class In-Reply-To: References: Message-ID: <177953502.20081117004901@gmail.com> Hello Maur??cio, Monday, November 17, 2008, 12:32:11 AM, you wrote: > class MyClass r where function :: r -> s this tells that f may return value of any type requested at the call site, i.e. one can write main = do print (f (Mydata 1) :: String) print (f (Mydata 1) :: [Bool]) print (f (Mydata 1) :: Either Double Float) > instance MyClass (MyData v) where function (MyData a) = a this definition can return value of only one type, so it can't serve all the calls i mentioned above > GHC says that the type of the result of 'function' is both determined by > the "rigid type" from MyClass and the "rigid type" from MyData. But why > can't both be the same? are you OOPer? :) ps: GHC error messages should be fired :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jgmorris at cecs.pdx.edu Sun Nov 16 16:56:02 2008 From: jgmorris at cecs.pdx.edu (J. Garrett Morris) Date: Sun Nov 16 16:50:16 2008 Subject: [Haskell-cafe] Type question in instance of a class In-Reply-To: References: Message-ID: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> On Sun, Nov 16, 2008 at 1:32 PM, Maur??cio wrote: > Hi, > > Why is this wrong? > > ---- > class MyClass r where function :: r -> s > > data MyData u = MyData u > > instance MyClass (MyData v) where function (MyData a) = a > ---- > > GHC says that the type of the result of 'function' is both determined by > the "rigid type" from MyClass and the "rigid type" from MyData. But why > can't both be the same? As Bulat said, your type signature is equivalent to: function :: forall r s. r -> s whereas the result you're producing can't produce any s, but only particular s's. In essence, the result type is determined by the input type. One way to code this would be to use functional dependencies: class MyClass r s | r -> s where function :: r -> s data MyData u = MyData u instance MyClass (MyData v) v where function (MyData a) = a /g -- I am in here From claudiusmaximus at goto10.org Sun Nov 16 17:01:20 2008 From: claudiusmaximus at goto10.org (Claude Heiland-Allen) Date: Sun Nov 16 16:55:37 2008 Subject: [Haskell-cafe] Type question in instance of a class In-Reply-To: References: Message-ID: <49209830.7020508@goto10.org> Maur??cio wrote: > Hi, > > Why is this wrong? > > ---- > class MyClass r where function :: r -> s > > data MyData u = MyData u > > instance MyClass (MyData v) where function (MyData a) = a > ---- > > GHC says that the type of the result of 'function' is both determined by > the "rigid type" from MyClass and the "rigid type" from MyData. But why > can't both be the same? particular instances can't add extra restrictions (eg: "both types are the same") to the interface declared by the class (eg: "both types are arbitrary"). Compare this version: ----8<---- {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} module Test where class MyClass r s where function :: r -> s data MyData u = MyData u instance MyClass (MyData v) v where function (MyData a) = a ----8<---- And ghci session: ----8<---- *Test> function (MyData "hello") :1:0: No instance for (MyClass (MyData [Char]) s) arising from a use of `function' at :1:0-24 Possible fix: add an instance declaration for (MyClass (MyData [Char]) s) In the expression: function (MyData "hello") In the definition of `it': it = function (MyData "hello") *Test> :t function (MyData "hello") function (MyData "hello") :: (MyClass (MyData [Char]) s) => s *Test> function (MyData "hello") :: String "hello" ----8<---- I don't know how evil those language extensions are, though - I just fiddled until it worked... > What am I doing wrong? Claude -- http://claudiusmaximus.goto10.org/ From bulat.ziganshin at gmail.com Sun Nov 16 17:03:08 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Nov 16 16:57:46 2008 Subject: [Haskell-cafe] Type question in instance of a class In-Reply-To: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> References: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> Message-ID: <1115545264.20081117010308@gmail.com> Hello J., Monday, November 17, 2008, 12:56:02 AM, you wrote: >> class MyClass r where function :: r -> s > As Bulat said, your type signature is equivalent to: > function :: forall r s. r -> s only function :: forall s. r -> s (r is fixed in class header) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dagit at codersbase.com Sun Nov 16 17:31:47 2008 From: dagit at codersbase.com (Jason Dagit) Date: Sun Nov 16 17:26:03 2008 Subject: [Haskell-cafe] Type question in instance of a class In-Reply-To: <49209830.7020508@goto10.org> References: <49209830.7020508@goto10.org> Message-ID: On Sun, Nov 16, 2008 at 2:01 PM, Claude Heiland-Allen < claudiusmaximus@goto10.org> wrote: > > I don't know how evil those language extensions are, though - I just > fiddled until it worked... The only part of FlexibleInstances that you've used here is the ability to mention a type variable more than once in the instance. I really wish this came with MultiParamTypeClasses. My reasoning is this, FlexibleInstances turns on a lot of extra stuff, as do functional dependencies. And yet, once you have multiparam type classes one of the natural things you want is the ability to mention a type variable more than once but currently you have to enable a lot of extra baggage to get that ability. I'm not an expert, the way you've used them together seems quite sane and by using those extensions instead of some of the more powerful ones you've probably done yourself a favor :) Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081116/2419593a/attachment.htm From jeremy at n-heptane.com Sun Nov 16 17:43:14 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Sun Nov 16 17:28:18 2008 Subject: [Haskell-cafe] HAPPS on a major hosting provider? In-Reply-To: <4165d3a70811161104r725ef9ddo477ccc2a65faaa4a@mail.gmail.com> References: <4165d3a70811161104r725ef9ddo477ccc2a65faaa4a@mail.gmail.com> Message-ID: <87fxlruwal.wl%jeremy@n-heptane.com> Hello, I have run HAppS applications on VPSs from vpslink.com and rimuhosting.com. If you want shared hosting, then you would need to get FastCGI support working again (I assume it has bitrotted somewhat). Because of HAppS's preference for storing everything in RAM, it is not really a shared-host friendly architecture. A $14.95/month 128MB VPS from vpslink seems to work fine as a entry-level solution though. - jeremy At Sun, 16 Nov 2008 14:04:51 -0500, Jefferson Heard wrote: > > I was wondering if anyone's ever tried to run Haaps on a major hosting > provider, like oh, say Site5? I have an app I'd otherwise use Rails > for and I thought I'd give Haaps a try... > > -- Jeff > > > I try to take things like a crow; war and chaos don't always ruin a > picnic, they just mean you have to be careful what you swallow. > > -- Jessica Edwards > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From phercek at gmail.com Sun Nov 16 19:06:08 2008 From: phercek at gmail.com (Peter Hercek) Date: Sun Nov 16 19:00:33 2008 Subject: [Haskell-cafe] Re: Type question in instance of a class In-Reply-To: <1115545264.20081117010308@gmail.com> References: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> <1115545264.20081117010308@gmail.com> Message-ID: Bulat Ziganshin wrote: > Hello J., > > Monday, November 17, 2008, 12:56:02 AM, you wrote: > >>> class MyClass r where function :: r -> s >> As Bulat said, your type signature is equivalent to: > >> function :: forall r s. r -> s > > only > > function :: forall s. r -> s > > (r is fixed in class header) > ... and the only value the function can return is bottom. Is there any type system which would have more than one value which inhabits all types? Peter. From lrpalmer at gmail.com Sun Nov 16 19:09:24 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun Nov 16 19:03:37 2008 Subject: [Haskell-cafe] Re: Type question in instance of a class In-Reply-To: References: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> <1115545264.20081117010308@gmail.com> Message-ID: <7ca3f0160811161609t5575ee0fh6f0bfcd574467cef@mail.gmail.com> On Sun, Nov 16, 2008 at 5:06 PM, Peter Hercek wrote: > ... and the only value the function can return is bottom. > Is there any type system which would have more than > one value which inhabits all types? Well something like lazy C# might; i.e. every value has a _|_ (nontermination) and null (termination but undefined). Luke From dave at zednenem.com Sun Nov 16 19:20:19 2008 From: dave at zednenem.com (David Menendez) Date: Sun Nov 16 19:14:32 2008 Subject: [Haskell-cafe] Re: Type question in instance of a class In-Reply-To: <7ca3f0160811161609t5575ee0fh6f0bfcd574467cef@mail.gmail.com> References: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> <1115545264.20081117010308@gmail.com> <7ca3f0160811161609t5575ee0fh6f0bfcd574467cef@mail.gmail.com> Message-ID: <49a77b7a0811161620h59501171of1fdc37d2d3f847f@mail.gmail.com> On Sun, Nov 16, 2008 at 7:09 PM, Luke Palmer wrote: > On Sun, Nov 16, 2008 at 5:06 PM, Peter Hercek wrote: >> ... and the only value the function can return is bottom. >> Is there any type system which would have more than >> one value which inhabits all types? > > Well something like lazy C# might; i.e. every value has a _|_ > (nontermination) and null (termination but undefined). For that matter, Control.Exception allows you to distinguish exceptional values from each other. -- Dave Menendez From wqeqweuqy at hotmail.com Sun Nov 16 19:36:16 2008 From: wqeqweuqy at hotmail.com (Neal Alexander) Date: Sun Nov 16 19:30:47 2008 Subject: [Haskell-cafe] Re: Haskell Weekly News: Issue 93 - November 15, 2008 In-Reply-To: <20081115205552.GA15664@seas.upenn.edu> References: <20081115205552.GA15664@seas.upenn.edu> Message-ID: Brent Yorgey wrote: > --------------------------------------------------------------------------- > ANN: OpenGL with extra type safety. Neal Alexander > Hopefully the code will be uploaded to Hackage as a separate package soon. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OGL-0.0.0 http://haskell.org/haskellwiki/OGL From mdmkolbe at gmail.com Sun Nov 16 20:10:36 2008 From: mdmkolbe at gmail.com (Michael D. Adams) Date: Sun Nov 16 20:04:52 2008 Subject: [Haskell-cafe] Find unused exports In-Reply-To: References: <916b84820811160535n494a67e7y99296053c3a55e6f@mail.gmail.com> Message-ID: Within a set of modules, the minimal imports also give you the minimal exports since each minimal export is required because it is imported somewhere. Just compile all your modules with -ddump-minimal-imports, then cat all your "*.import" files together and sort the result. The minimal exports for module Foo will be listed as several lines of the form "import Foo(x,y,z)", etc. From there on it's just a bit of text munging to get it into your export list code (about two lines of perl). Michael D. Adams 2008/11/16 Jason Dagit : > > > On Sun, Nov 16, 2008 at 5:35 AM, Thomas Schilling > wrote: >> The relevant flag is: -ddump-minimal-imports >> >> See >> http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id2630684 > > The documentation says this: >> >> -ddump-minimal-imports >> >> Dump to the file "M.imports" (where M is the module being compiled) a >> "minimal" set of import declarations. You can safely replace all the import >> declarations in "M.hs" with those found in "M.imports". Why would you want >> to do that? Because the "minimal" imports (a) import everything explicitly, >> by name, and (b) import nothing that is not required. It can be quite >> painful to maintain this property by hand, so this flag is intended to >> reduce the labour. > > I already know the minimal set of import for the modules. That's why I > mentioned using -Wall; ghc will complain if you import something and don't > use it. > > The problem is that you can export names that never get used in other > modules. I would like a tool that can look over a project and tell me which > exported names are never imported. These names correspond to things that > can be removed from the project. > > Thanks, > Jason > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From dagit at codersbase.com Sun Nov 16 20:48:27 2008 From: dagit at codersbase.com (Jason Dagit) Date: Sun Nov 16 20:42:42 2008 Subject: [Haskell-cafe] Find unused exports In-Reply-To: References: <916b84820811160535n494a67e7y99296053c3a55e6f@mail.gmail.com> Message-ID: On Sun, Nov 16, 2008 at 5:10 PM, Michael D. Adams wrote: > Within a set of modules, the minimal imports also give you the minimal > exports since each minimal export is required because it is imported > somewhere. Just compile all your modules with -ddump-minimal-imports, > then cat all your "*.import" files together and sort the result. The > minimal exports for module Foo will be listed as several lines of the > form "import Foo(x,y,z)", etc. From there on it's just a bit of text > munging to get it into your export list code (about two lines of > perl). Alright, that's the same manual process I do now. I didn't use -ddump-minimal-imports before because I didn't know about it and we maintain sufficiently minimal imports already. That and I used emacs macros instead of perl because I already know how to use emacs :) If I take the time to automate this I wonder if it's a worthwhile tool to upload to hackage. Sounds like others have been doing this sort of thing. Now if I just had a round touit... Thanks everyone! Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081116/aa9937c7/attachment.htm From silviu.andrica at epfl.ch Mon Nov 17 06:04:42 2008 From: silviu.andrica at epfl.ch (Silviu ANDRICA) Date: Mon Nov 17 05:58:57 2008 Subject: [Haskell-cafe] Proof of a multi-threaded application Message-ID: <49214FCA.8060004@epfl.ch> Hello, I am very new to Haskell, this is my first day, and I wanted to know if it is possible to prove correctness of a multi-threaded application written in Haskell. Basically, I want to check that a multi-threaded implementation of an algorithm that detects cycles in a dynamically changing graph, actually detects the cycles. Also, the algorithm prevents previously detected cycles from happening by not allowing certain edges to be added. And I want to check that this property also holds. Thank you and I hope you can help me, Silviu ANDRICA. From lemming at henning-thielemann.de Mon Nov 17 06:27:49 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Nov 17 06:22:03 2008 Subject: [Haskell-cafe] Re: OpenGL -> OGL In-Reply-To: References: <20081115205552.GA15664@seas.upenn.edu> Message-ID: On Sun, 16 Nov 2008, Neal Alexander wrote: > Brent Yorgey wrote: >> --------------------------------------------------------------------------- >> ANN: OpenGL with extra type safety. Neal Alexander >> Hopefully the code will be uploaded to Hackage as a separate package soon. > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OGL-0.0.0 > http://haskell.org/haskellwiki/OGL I'd prefer a more descriptive package name like safe-opengl or so. From lrpalmer at gmail.com Mon Nov 17 07:52:47 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Nov 17 07:47:01 2008 Subject: [Haskell-cafe] Proof of a multi-threaded application In-Reply-To: <49214FCA.8060004@epfl.ch> References: <49214FCA.8060004@epfl.ch> Message-ID: <7ca3f0160811170452v1d405933qf87e6129865c2e89@mail.gmail.com> On Mon, Nov 17, 2008 at 4:04 AM, Silviu ANDRICA wrote: > Hello, > I am very new to Haskell, this is my first day, and I wanted to know if it > is possible to prove correctness of a multi-threaded application written in > Haskell. > Basically, I want to check that a multi-threaded implementation of an > algorithm that detects cycles in a dynamically changing graph, actually > detects the cycles. Also, the algorithm prevents previously detected cycles > from happening by not allowing certain edges to be added. And I want to > check that this property also holds. This is going to be difficult -- no matter what language you try to prove it in. In Haskell you have a decent shot, I suppose, since you could at least prove the pure bits correct without much fuss. The way I might try to approach this is to model your algorithm and the dynamically changing graph together as a nondeterministic state machine: a function of type State -> [State] (returning all the possible "next steps" of the system). Then I would look for some invariant that is preserved at each step, and prove its preservation. That is how you could prove your *algorithm* correct. But I suspect there will be many difficulties proving that your implementation corresponds to your algorithm. This is mostly because in the IO monad, "anything goes"; i.e. the semantics are complex and mostly unknown. You might make some progress by isolating a small portion of the IO monad and assuming that it obeys some particular reasonable nondeterministic semantics. But that will be a large, intuitive assumption which will decrease the degree of certainty of your proof. If you implement your algorithm in terms of STM (one of Haskell's flaunting points :-) rather than more traditional primitives (eg. locks) you will have a better shot, since you can more easily show that an invariant is kept before and after a transaction, without having to fuss with the concurrency details inside where the invariant is briefly broken. Concurrency is quite hard to reason about formally (no matter what language it is in). Good luck! Luke From ketil at malde.org Mon Nov 17 08:05:06 2008 From: ketil at malde.org (Ketil Malde) Date: Mon Nov 17 07:59:19 2008 Subject: [Haskell-cafe] Proof of a multi-threaded application In-Reply-To: <7ca3f0160811170452v1d405933qf87e6129865c2e89@mail.gmail.com> (Luke Palmer's message of "Mon\, 17 Nov 2008 05\:52\:47 -0700") References: <49214FCA.8060004@epfl.ch> <7ca3f0160811170452v1d405933qf87e6129865c2e89@mail.gmail.com> Message-ID: <87wsf2jyf1.fsf@malde.org> "Luke Palmer" writes: > STM My apologies for side-tracking, but does anybody have performance numbers for STM? I have an application waiting to be written using STM, boldly parallelizing where no man has parallelized before, but if it doesn't make it faster, the whole excercise gets a lot less convincing. Most material I find seems to be of the proof-of-concept kind. -k -- If I haven't seen further, it is by standing in the footprints of giants From briqueabraque at yahoo.com Mon Nov 17 13:38:06 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Mon Nov 17 13:32:31 2008 Subject: [Haskell-cafe] Re: Type question in instance of a class In-Reply-To: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> References: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> Message-ID: >> Why is this wrong? (...) > (...) One way to code this would be to use functional dependencies: > > class MyClass r s | r -> s where function :: r -> s > data MyData u = MyData u > instance MyClass (MyData v) v where function (MyData a) = a One additional problem is that I (believe I) need that my class takes just one type, since I'm trying to derive it in a new type (using generalized newtype deriving). A good comparison would be a complex number over any float type. I could define a few operations like: makeComplex r i = ComplexNumber r i realPart (ComplexNumber r _) = r But then I would like to say: newtype ComplexWithDouble = ComplexWithDouble (ComplexNumber Double) deriving ... so that I could have: a :: ComplexWithDouble a = makeComplex 0.5 0.25 My first attempt was to try some kind of "type pattern match" :) like class ComplexBaseClass (c r) where ... but it seems that doesn't make sense. Thanks for your tips, Maur?cio From briqueabraque at yahoo.com Mon Nov 17 13:39:18 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Mon Nov 17 13:34:17 2008 Subject: [Haskell-cafe] Re: OOPer? In-Reply-To: <177953502.20081117004901@gmail.com> References: <177953502.20081117004901@gmail.com> Message-ID: (...) >> GHC says that the type of the result of 'function' is both determined by >> the "rigid type" from MyClass and the "rigid type" from MyData. But why >> can't both be the same? > > are you OOPer? :) > What is an OOPer? From jonathanccast at fastmail.fm Mon Nov 17 13:48:21 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Nov 17 13:42:43 2008 Subject: [Haskell-cafe] Re: OOPer? In-Reply-To: References: <177953502.20081117004901@gmail.com> Message-ID: <1226947701.25951.10.camel@jcchost> On Mon, 2008-11-17 at 16:39 -0200, Maur??cio wrote: > (...) > >> GHC says that the type of the result of 'function' is both determined by > >> the "rigid type" from MyClass and the "rigid type" from MyData. But why > >> can't both be the same? > > > > are you OOPer? :) > > > > What is an OOPer? Object-Oriented Programmer. A species that frequently finds Haskell type classes and polymorphism very confusing. (Hint: the similarity between Haskell type classes and OO classes pretty much begins and ends at the name. Similarly for Haskell/ML polymorphism and OO polymorphism. They have points of similarity, but on net the best plan is to simply never reason analogically from one to the other.) jcc From garious at gmail.com Mon Nov 17 14:00:30 2008 From: garious at gmail.com (Greg Fitzgerald) Date: Mon Nov 17 13:54:42 2008 Subject: [Haskell-cafe] Re: OOPer? In-Reply-To: <1226947701.25951.10.camel@jcchost> References: <177953502.20081117004901@gmail.com> <1226947701.25951.10.camel@jcchost> Message-ID: <1f3dc80d0811171100h7394e3a2p1740cc17846c7195@mail.gmail.com> Jonathan Cast wrote: > [Functional and object-oriented programming] have points of similarity, but on net the > best plan is to simply never reason analogically from one to the other. Coming from the OO world, I found it very useful to see how the same solution is modeled using different paradigms. I don't recall where I found the following example, but copied it locally as compelling evidence that the functional solution can be much clearer and shorter than the same solution modeled with objects and inheritance. -- Arithmetic expression forms data Expr = Num Int | Add Expr Expr -- Evaluate expressions eval :: Expr -> Int eval (Num i) = i eval (Add l r ) = eval l + eval r -- Modify literals modulo v modn :: Expr -> Int -> Expr modn (Num i) v = Num (i 'mod' v) modn (Add l r) v = Add (modn l v) (modn r v) public abstract class Expr { public abstract int eval (); public abstract void modn(int v); } public class Num extends Expr { private int value; public Num(int value) { this.value = value; } public int eval () { return value; } public void modn(int v) { this.value = this.value % v; } public class Add extends Expr { private Expr left, right; public Add(Expr left, Expr right ) { this.left = left; this.right = right; } public int eval () { return left.eval () + right.eval (); } public void modn(int v) { left.modn(v); right.modn(v); } } -Greg From bulat.ziganshin at gmail.com Mon Nov 17 13:55:03 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Nov 17 13:59:34 2008 Subject: [Haskell-cafe] Re: Type question in instance of a class In-Reply-To: References: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> Message-ID: <10610220603.20081117215503@gmail.com> Hello Maur??cio, Monday, November 17, 2008, 9:38:06 PM, you wrote: >> (...) One way to code this would be to use functional dependencies: >> >> class MyClass r s | r -> s where function :: r -> s > One additional problem is that I (believe I) need that my class takes > just one type FDs with just one type parameter are called ATs :) (FDs = functional dependencies, ATs is a new feature of ghc 6.8/6.10) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From leimy2k at gmail.com Mon Nov 17 15:36:02 2008 From: leimy2k at gmail.com (David Leimbach) Date: Mon Nov 17 15:30:16 2008 Subject: [Haskell-cafe] Re: OOPer? In-Reply-To: References: <177953502.20081117004901@gmail.com> Message-ID: <3e1162e60811171236o991d635h2aeb6509566b1c9d@mail.gmail.com> On Mon, Nov 17, 2008 at 10:39 AM, Maur??cio wrote: > (...) > >> GHC says that the type of the result of 'function' is both determined by >>> the "rigid type" from MyClass and the "rigid type" from MyData. But why >>> can't both be the same? >>> >> >> are you OOPer? :) >> >> > What is an OOPer? > I think, from the OOP point of view, that it is useful to think of classes as collections of generic functions that may apply to different types, if they happen to implement that class of functions. (Would it then be fair to equate a Haskell class to a Java Interface, but not to a Java class?) Type are more about a range of values allowed than about functionality, as they are in OOP languages when defined by OOP classes. The class/data type system in Haskell really does feel to me to be more like CLOS than like C++/Java. But then I barely touched CLOS for a brief moment in time to feel that way, so it's not a strong feeling :-) Dave > > _______________________________________________ > 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/20081117/4c7484f4/attachment.htm From timd at macquarie.com.au Mon Nov 17 17:59:55 2008 From: timd at macquarie.com.au (Tim Docker) Date: Mon Nov 17 17:54:09 2008 Subject: [Haskell-cafe] Proof of a multi-threaded application In-Reply-To: <87wsf2jyf1.fsf@malde.org> References: <49214FCA.8060004@epfl.ch><7ca3f0160811170452v1d405933qf87e6129865c2e89@mail.gmail.com> <87wsf2jyf1.fsf@malde.org> Message-ID: <9A015D433594EA478964C5B34AF3179B0247D069@ntsydexm06.pc.internal.macquarie.com> Ketil Malde wrote: > My apologies for side-tracking, but does anybody have performance > numbers for STM? I have an application waiting to be written using > STM, boldly parallelizing where no man has parallelized before, but > if it doesn't make it faster, the whole excercise gets a lot less > convincing. Most material I find seems to be of the proof-of-concept > kind. Faster than what? I've used STM for a real application, and the main benefit I saw was in using a set of primitives that facilitate writing concurrent code that is clearer and more likely to be correct. Performance is fine - given it is IO bound, the time taken by STM is not an issue in this case. Are you considering using STM just to make otherwise pure code run in parallel on multiple cores? If so, then perhaps the pure parallelisation primitives are more appropriate. Tim From jgmorris at cecs.pdx.edu Mon Nov 17 18:07:27 2008 From: jgmorris at cecs.pdx.edu (J. Garrett Morris) Date: Mon Nov 17 18:01:37 2008 Subject: [Haskell-cafe] Re: Type question in instance of a class In-Reply-To: References: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> Message-ID: <6cf91caa0811171507h5477df33xd36418a9199a7db7@mail.gmail.com> On Mon, Nov 17, 2008 at 10:38 AM, Maur??cio wrote: > newtype ComplexWithDouble = ComplexWithDouble (ComplexNumber Double) > deriving ... Perhaps you want something like: class Complex r c | c -> r where makeComplex :: r -> r -> c realPart :: c -> r imagPart :: c -> r data ComplexNumber t = CN t t instance Complex t (ComplexNumber t) where makeComplex = CN realPart (CN r _) = r imagPart (CN _ i) = i newtype ComplexWithDouble = CWD (ComplexNumber Double) deriving (Complex Double) Having the parameters "backwards" is somewhat annoying, I suppose, but it's unavoidable if you're hoping to use generalized newtype deriving I believe. /g -- I am in here From min at cse.unsw.edu.au Mon Nov 17 18:28:25 2008 From: min at cse.unsw.edu.au (Kyongho Min) Date: Mon Nov 17 18:22:39 2008 Subject: [Haskell-cafe] How to make interface IO() to IO a in a command-driven tool Message-ID: <4921FE19.6020409@cse.unsw.edu.au> Dear Haskell users, I am working on a command-driven tool (::IO ()). If the system invokes itself again, and the system's returned data type would be 'IO a', say (IO Exp) (Expression). tool:: a -> IO() The nested tool invocation returns (IO Exp) to the previous tool. I am using dynamic error exception handling like (throwDyn exp). If I use 'forkIO', then it works for this situation (e.g. IO Exp) but it is not working for 'quit' command (quit the tool:: thread blocked indefinitely) - quit the subtool and return to the previous tool. Any suggestion would be helpful? tool = {tool1, tool2, tool3, ...} tool1:: (IO ()) invoked tool2:: (IO a) may invoked tool3:: (IO a) tool2 is working basically on IO() and if I got the Exp (proved), then return it to the previous tool (say tool1). Thanks in advance, min From briqueabraque at yahoo.com Mon Nov 17 18:49:50 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Mon Nov 17 18:44:11 2008 Subject: [Haskell-cafe] Re: [off-topic] OOPer? In-Reply-To: <1f3dc80d0811171100h7394e3a2p1740cc17846c7195@mail.gmail.com> References: <177953502.20081117004901@gmail.com> <1226947701.25951.10.camel@jcchost> <1f3dc80d0811171100h7394e3a2p1740cc17846c7195@mail.gmail.com> Message-ID: > (...) I don't recall where I found the following example, but copied > it locally as compelling evidence that the functional solution can be > much clearer and shorter than the same solution modeled with objects > and inheritance. Greg, I desagree with you. Bjarne Stroustrup, the original creator of C++, is a sensible person and I share his peacefull opinion in this matter: http://www.research.att.com/~bs/bs_faq.html#compare Even with good intentions, I've never seen such kind of comparison not to fall into religious fights. (Although I'm not more than just a humble language user.) > -- Arithmetic expression forms data Expr = Num Int | Add Expr Expr > > -- Evaluate expressions > eval :: Expr -> Int > (...) > public abstract class Expr { > public abstract int eval (); > public abstract void modn(int v); Although I'm not good enough to judge anyone's Haskell code, the Haskell version seems nice. I don't know how someone who understands well object-oriented code would do that. But I did C++ until around 1998, when the first standard was set, and I can tell you for sure that, even at that time, no one who knows at least the basics of C++ would ever write that problem like this. Best, Maur?cio From jonathanccast at fastmail.fm Mon Nov 17 19:04:54 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Nov 17 18:59:13 2008 Subject: [Haskell-cafe] Re: [off-topic] OOPer? In-Reply-To: References: <177953502.20081117004901@gmail.com> <1226947701.25951.10.camel@jcchost> <1f3dc80d0811171100h7394e3a2p1740cc17846c7195@mail.gmail.com> Message-ID: <1226966694.25951.43.camel@jcchost> On Mon, 2008-11-17 at 21:49 -0200, Maur??cio wrote: > > (...) I don't recall where I found the following example, but copied > > it locally as compelling evidence that the functional solution can be > > much clearer and shorter than the same solution modeled with objects > > and inheritance. > > Greg, > > I desagree with you. Bjarne Stroustrup, the original creator of C++, is > a sensible person I think his creation of C++ is evidence against that view... > and I share his peacefull opinion in this matter: > > http://www.research.att.com/~bs/bs_faq.html#compare > > Even with good intentions, I've never seen such kind of comparison not > to fall into religious fights. How do you recommend selecting a language? Stroustrup, in my experience, seems to think the answer is `any method but technical merits', which would make me suspicious of the technical merits of his solution even if I knew nothing else about them (and I know all too much...). Ask yourself: what is he hiding? > > -- Arithmetic expression forms data Expr = Num Int | Add Expr Expr > > > > -- Evaluate expressions > > eval :: Expr -> Int > > (...) > > > public abstract class Expr { > > public abstract int eval (); > > public abstract void modn(int v); > > Although I'm not good enough to judge anyone's Haskell code, the Haskell > version seems nice. I don't know how someone who understands well > object-oriented code would do that. But I did C++ until around 1998, > when the first standard was set, and I can tell you for sure that, even > at that time, no one who knows at least the basics of C++ would ever > write that problem like this. Of course not. But their solution wouldn't be object-oriented, either; this is just an example where OO solutions don't make sense. (And the example code is Java; I've been wracking my brain, but I can't come up with any other way to do it in that language). jcc From daniel.yokomizo at gmail.com Mon Nov 17 19:24:14 2008 From: daniel.yokomizo at gmail.com (Daniel Yokomizo) Date: Mon Nov 17 19:18:25 2008 Subject: [Haskell-cafe] Re: [off-topic] OOPer? In-Reply-To: References: <177953502.20081117004901@gmail.com> <1226947701.25951.10.camel@jcchost> <1f3dc80d0811171100h7394e3a2p1740cc17846c7195@mail.gmail.com> Message-ID: On Mon, Nov 17, 2008 at 9:49 PM, Maur??cio wrote: > > (...) I don't recall where I found the following example, but copied > > it locally as compelling evidence that the functional solution can be > > much clearer and shorter than the same solution modeled with objects > > and inheritance. > > Greg, > > I desagree with you. Bjarne Stroustrup, the original creator of C++, is > a sensible person and I share his peacefull opinion in this matter: > > http://www.research.att.com/~bs/bs_faq.html#compare > > Even with good intentions, I've never seen such kind of comparison not > to fall into religious fights. (Although I'm not more than just a humble > language user.) > Functional languages are much more formalized than OO languages. The basics (i.e. lambda-calculus algebraic data-types, *morphisms) are well known and very composable. OO theory is a mess, classes and objects are different beasts on every OO language and they don't form an easily composable toolkit (e.g. the inheritance vs. composition debate, where to place methods, binary method choices). There are many (which by sheer amount of variance isn't a good sign) formalizations of OO but none that were well received by the most popular OOPLs (in contrast with FP theory and it's pervasiveness in FPLs). In this case it isn't a religious fight. > > > -- Arithmetic expression forms data Expr = Num Int | Add Expr Expr > > > > -- Evaluate expressions > > eval :: Expr -> Int > > (...) > > > public abstract class Expr { > > public abstract int eval (); > > public abstract void modn(int v); > > Although I'm not good enough to judge anyone's Haskell code, the Haskell > version seems nice. I don't know how someone who understands well > object-oriented code would do that. But I did C++ until around 1998, > when the first standard was set, and I can tell you for sure that, even > at that time, no one who knows at least the basics of C++ would ever > write that problem like this. > Well, any OO programmer familiar with algebraic and coalgebraic datatypes would do that, it's the best way to model this problem (unless you mix it with extensible types but then we would fall in the expression problem territory and this isn't an easy problem to solve in any mainstream languages). Best, > Maur?cio Best regards, Daniel Yokomizo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081117/2ba20cee/attachment.htm From derek.a.elkins at gmail.com Mon Nov 17 19:30:58 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Mon Nov 17 19:25:14 2008 Subject: [Haskell-cafe] Re: [off-topic] OOPer? In-Reply-To: <1226966694.25951.43.camel@jcchost> References: <177953502.20081117004901@gmail.com> <1226947701.25951.10.camel@jcchost> <1f3dc80d0811171100h7394e3a2p1740cc17846c7195@mail.gmail.com> <1226966694.25951.43.camel@jcchost> Message-ID: <1226968258.15731.24.camel@derek-laptop> On Mon, 2008-11-17 at 16:04 -0800, Jonathan Cast wrote: > On Mon, 2008-11-17 at 21:49 -0200, Maur??cio wrote: > > > (...) I don't recall where I found the following example, but copied > > > it locally as compelling evidence that the functional solution can be > > > much clearer and shorter than the same solution modeled with objects > > > and inheritance. > > > > Greg, > > > > I desagree with you. Bjarne Stroustrup, the original creator of C++, is > > a sensible person > > I think his creation of C++ is evidence against that view... > > > and I share his peacefull opinion in this matter: > > > > http://www.research.att.com/~bs/bs_faq.html#compare > > > > Even with good intentions, I've never seen such kind of comparison not > > to fall into religious fights. > > How do you recommend selecting a language? Stroustrup, in my > experience, seems to think the answer is `any method but technical > merits', which would make me suspicious of the technical merits of his > solution even if I knew nothing else about them (and I know all too > much...). Ask yourself: what is he hiding? > > > > -- Arithmetic expression forms data Expr = Num Int | Add Expr Expr > > > > > > -- Evaluate expressions > > > eval :: Expr -> Int > > > (...) > > > > > public abstract class Expr { > > > public abstract int eval (); > > > public abstract void modn(int v); > > > > Although I'm not good enough to judge anyone's Haskell code, the Haskell > > version seems nice. I don't know how someone who understands well > > object-oriented code would do that. But I did C++ until around 1998, > > when the first standard was set, and I can tell you for sure that, even > > at that time, no one who knows at least the basics of C++ would ever > > write that problem like this. > > Of course not. But their solution wouldn't be object-oriented, either; > this is just an example where OO solutions don't make sense. (And the > example code is Java; I've been wracking my brain, but I can't come up > with any other way to do it in that language). Jonathan is spot on. The OO solution is an elegant approach. I can definitely see a C++ programmer writing it. If they didn't write it that way, it would be because, as Jonathan says, they didn't use an OOP approach. Note that this particular example is usually used to show the duality between FP and OOP. To add a prettyPrint function to the FP version, one need simply write another function while the OOP version will require changes to all the classes. To add a Mul constructor to the OOP version, one need simply write another class while the FP version will require changes to all the functions. This example illustrates (and is the namesake of) the expression problem. From Ivan.Miljenovic at gmail.com Mon Nov 17 19:36:34 2008 From: Ivan.Miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon Nov 17 19:30:54 2008 Subject: [Haskell-cafe] Re: Find unused exports References: Message-ID: Jason Dagit codersbase.com> writes: > > Hello, > > Has anyone already made a tool to check if exported functions, data > constructors, types, etc are unused within a set of modules? My SourceGraph programme (available on Hackage) can do this with a few caveats: 1) Only supports functions, not data constructors, types, etc. 2) The project must be Cabalized 3) The functions exported must not be available from the library (though if it's an executable, then it will return all non-called functions that aren't called "main"). > > For my usage it would probably suffice if the tool only compared > import lists against export lists This is basically what SourceGraph does. Note that it hasn't been upgraded to GHC-6.10 yet, nor the HSE-4 series. From dagit at codersbase.com Mon Nov 17 19:46:18 2008 From: dagit at codersbase.com (Jason Dagit) Date: Mon Nov 17 19:40:29 2008 Subject: [Haskell-cafe] Re: Find unused exports In-Reply-To: References: Message-ID: On Mon, Nov 17, 2008 at 4:36 PM, Ivan Lazar Miljenovic < Ivan.Miljenovic@gmail.com> wrote: > Jason Dagit codersbase.com> writes: > > > > > Hello, > > > > Has anyone already made a tool to check if exported functions, data > > constructors, types, etc are unused within a set of modules? > > My SourceGraph programme (available on Hackage) can do this with a few > caveats: > 1) Only supports functions, not data constructors, types, etc. > 2) The project must be Cabalized > 3) The functions exported must not be available from the library (though if > it's > an executable, then it will return all non-called functions that aren't > called > "main"). Those restrictions should fit my case very well. I have a .cabal file, I'm mainly interested in functions, and it's just an executable not a library. > > > > > > For my usage it would probably suffice if the tool only compared > > import lists against export lists > > This is basically what SourceGraph does. > > Note that it hasn't been upgraded to GHC-6.10 yet, nor the HSE-4 series. I don't think that will be a problem. I still haven't upgraded to 6.10 due to it uninstalling 6.8 (has anyone fixed this on osx yet?). And we don't use view patterns so HSE-4 is hopefully not needed. Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081117/69343a8f/attachment.htm From jeffzaroyko at gmail.com Mon Nov 17 20:04:04 2008 From: jeffzaroyko at gmail.com (Jeff Zaroyko) Date: Mon Nov 17 19:58:19 2008 Subject: [Haskell-cafe] Haskell library support In-Reply-To: <5ae4f2ba0811141336r26b4e39h79b7076bbbcdee5e@mail.gmail.com> References: <5ae4f2ba0811141336r26b4e39h79b7076bbbcdee5e@mail.gmail.com> Message-ID: 2008/11/15 Galchin, Vasili : > Hello, > > I am looking for something to work on. Where are there perceived holes > in the Haskell library support? > > Regards, Vasili Hello Vasili Maybe the haskell.org wiki would be a good place for people to record their suggestions? http://haskell.org/haskellwiki/Wanted_libraries looks like a suitable place. Regards, Jeff From reiner.pope at gmail.com Mon Nov 17 20:36:49 2008 From: reiner.pope at gmail.com (Reiner Pope) Date: Mon Nov 17 20:31:00 2008 Subject: [Haskell-cafe] Statically dimension-checked hmatrix Message-ID: <4cf038ee0811171736y31445d25q718db816f707601b@mail.gmail.com> Hi, What is the situation regarding statically dimension-checked linear algebra libraries? It seems that Frederik Eaton was working on one in 2006 (see the paper "Statically typed linear algebra in Haskell"), and he produced the Vectro library from this, based on GSLHaskell. Are there any more recent efforts into this, particularly using the new TFs? If not, I might have a go at it, as a thin wrapper for hmatrix. Cheers, Reiner From garious at gmail.com Mon Nov 17 21:13:02 2008 From: garious at gmail.com (Greg Fitzgerald) Date: Mon Nov 17 21:07:12 2008 Subject: [Haskell-cafe] Re: OOPer? In-Reply-To: <1f3dc80d0811171100h7394e3a2p1740cc17846c7195@mail.gmail.com> References: <177953502.20081117004901@gmail.com> <1226947701.25951.10.camel@jcchost> <1f3dc80d0811171100h7394e3a2p1740cc17846c7195@mail.gmail.com> Message-ID: <1f3dc80d0811171813g5fc1b15do775262a4ec66a8e@mail.gmail.com> I wrote: > I don't recall where I found the following example My apologies to Ralf Lammel and Ondrej Rypacek. Five seconds on Google tells me I had copied that code verbatim from their paper, "The expression lemma." http://www.uni-koblenz.de/~laemmel/expression/long.pdf Great paper, by the way! -Greg On Mon, Nov 17, 2008 at 11:00 AM, Greg Fitzgerald wrote: > Jonathan Cast wrote: >> [Functional and object-oriented programming] have points of similarity, but on net the >> best plan is to simply never reason analogically from one to the other. > > Coming from the OO world, I found it very useful to see how the same > solution is modeled using different paradigms. I don't recall where I > found the following example, but copied it locally as compelling > evidence that the functional solution can be much clearer and shorter > than the same solution modeled with objects and inheritance. > > -- Arithmetic expression forms > data Expr = Num Int | Add Expr Expr > > -- Evaluate expressions > eval :: Expr -> Int > eval (Num i) = i > eval (Add l r ) = eval l + eval r > > -- Modify literals modulo v > modn :: Expr -> Int -> Expr > modn (Num i) v = Num (i 'mod' v) > modn (Add l r) v = Add (modn l v) (modn r v) > > > > public abstract class Expr { > public abstract int eval (); > public abstract void modn(int v); > } > > public class Num extends Expr { > private int value; > public Num(int value) { this.value = value; } > public int eval () { return value; } > public void modn(int v) { this.value = this.value % v; > } > > public class Add extends Expr { > private Expr left, right; > public Add(Expr left, Expr right ) { this.left = left; this.right = right; } > public int eval () { return left.eval () + right.eval (); } > public void modn(int v) { left.modn(v); right.modn(v); } > } > > -Greg > From ketil at malde.org Tue Nov 18 01:35:43 2008 From: ketil at malde.org (Ketil Malde) Date: Tue Nov 18 01:29:56 2008 Subject: [Haskell-cafe] Proof of a multi-threaded application In-Reply-To: <9A015D433594EA478964C5B34AF3179B0247D069@ntsydexm06.pc.internal.macquarie.com> (Tim Docker's message of "Tue\, 18 Nov 2008 09\:59\:55 +1100") References: <49214FCA.8060004@epfl.ch> <7ca3f0160811170452v1d405933qf87e6129865c2e89@mail.gmail.com> <87wsf2jyf1.fsf@malde.org> <9A015D433594EA478964C5B34AF3179B0247D069@ntsydexm06.pc.internal.macquarie.com> Message-ID: <877i71ils0.fsf@malde.org> "Tim Docker" writes: >> My apologies for side-tracking, but does anybody have performance >> numbers for STM? I have an application waiting to be written using >> STM, boldly parallelizing where no man has parallelized before, but >> if it doesn't make it faster, > Faster than what? Faster than an equivalent non-concurrent program. It'd also be nice if performance was comparable lock-based implementation. > Are you considering using STM just to make otherwise pure code run in > parallel on multiple cores? No, I have a complex structure that must be updated in non-predictable ways. That's what STM is for, no? -k -- If I haven't seen further, it is by standing in the footprints of giants From conal at conal.net Tue Nov 18 02:03:52 2008 From: conal at conal.net (Conal Elliott) Date: Tue Nov 18 01:58:01 2008 Subject: [Haskell-cafe] simple generic / data view library? Message-ID: Is there a simple existing library that provides views of data types in terms of unit, product and sum? Here's what I threw together for my own use. I used associated types, though functional dependencies would work as well. class HasView t where type View t view :: t -> View t unview :: View t -> t -- View instances instance HasView (Maybe a) where type View (Maybe a) = Either () a view Nothing = (Left ()) view (Just a) = (Right a) unview (Left ()) = Nothing unview (Right a) = (Just a) instance HasView [a] where type View [a] = Either () (a,[a]) view [] = (Left ()) view (a:as) = (Right (a,as)) unview (Left ()) = [] unview (Right (a,as)) = (a:as) onView2 :: (HasView a, HasView b, HasView c) => (View a -> View b -> View c) -> (a -> b -> c) onView2 op a b = unview (view a `op` view b) Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081117/b3c1e5a8/attachment.htm From jpm at cs.uu.nl Tue Nov 18 02:11:30 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Tue Nov 18 02:05:40 2008 Subject: [Haskell-cafe] simple generic / data view library? In-Reply-To: References: Message-ID: <52f14b210811172311j565f8b56h8751ad941bbb92e@mail.gmail.com> Hello Conal, What you've done looks very much like the Regular datatype [1] in the rewriting library [2]. The rewriting library, as its name indicates, is very much targeted at rewriting. For a more complete library using a sum of products view (and without type synonyms), try the new release of EMGM [3]. Cheers, Pedro [1] http://hackage.haskell.org/packages/archive/rewriting/0.1/doc/html/Generics-Regular-Rewriting-Representations.html#t%3ARegular [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/rewriting [3] http://www.cs.uu.nl/wiki/bin/view/GenericProgramming/EMGM 2008/11/18 Conal Elliott > Is there a simple existing library that provides views of data types in > terms of unit, product and sum? > > Here's what I threw together for my own use. I used associated types, > though functional dependencies would work as well. > > class HasView t where > type View t > view :: t -> View t > unview :: View t -> t > > -- View instances > > instance HasView (Maybe a) where > type View (Maybe a) = Either () a > > view Nothing = (Left ()) > view (Just a) = (Right a) > > unview (Left ()) = Nothing > unview (Right a) = (Just a) > > > instance HasView [a] where > type View [a] = Either () (a,[a]) > > view [] = (Left ()) > view (a:as) = (Right (a,as)) > > unview (Left ()) = [] > unview (Right (a,as)) = (a:as) > > > onView2 :: (HasView a, HasView b, HasView c) => > (View a -> View b -> View c) > -> (a -> b -> c) > onView2 op a b = unview (view a `op` view b) > > Thanks, - Conal > > _______________________________________________ > 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/20081118/d8cbb906/attachment.htm From ryani.spam at gmail.com Tue Nov 18 02:14:14 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Nov 18 02:08:24 2008 Subject: [Haskell-cafe] Proof of a multi-threaded application In-Reply-To: <877i71ils0.fsf@malde.org> References: <49214FCA.8060004@epfl.ch> <7ca3f0160811170452v1d405933qf87e6129865c2e89@mail.gmail.com> <87wsf2jyf1.fsf@malde.org> <9A015D433594EA478964C5B34AF3179B0247D069@ntsydexm06.pc.internal.macquarie.com> <877i71ils0.fsf@malde.org> Message-ID: <2f9b2d30811172314n45cab75dybd26f36d3aca8c58@mail.gmail.com> If you have multiple agents interacting with some structure and you want it to look like each of them is accessing it serialized, then STM is exactly what you want. The performance is always "in comparison to what"; you will likely get worse performance than the "best possible" implementation of your algorithm using locks, but that algorithm may be very difficult to write. My intuition is that if you spend put two programmers on a task, one using STM and one using locks, that the STM solution will perform better given the same amount of implementation time for any non-trivial problem. In addition, you can choose the level of "fine-grained-ness" in STM just as you can with locks, by choosing what things to make into TVars and what things to make pure. For example, this structure: > type STMMap a = TVar (Map k a) will have much different performance than > type STMMap k a = TVar (STMNode a) > data STMNode a = Tip | Branch !k a (STMMap k a) (STMMap k a) and either one could be better depending on what you are doing. The former is like a "global lock" on the map, whereas the latter is analgous to "fine-grained" locks. But writing an algorithm using the "fine grained locks" version is a lot simpler to get right in STM than doing so with locks directly. In addition, STM's "optimistic concurrency" gives you the equivalent of multiple-reader single-writer locks for free; writing code with those directly is even more difficult to get right! -- ryan On Mon, Nov 17, 2008 at 10:35 PM, Ketil Malde wrote: > "Tim Docker" writes: > >>> My apologies for side-tracking, but does anybody have performance >>> numbers for STM? I have an application waiting to be written using >>> STM, boldly parallelizing where no man has parallelized before, but >>> if it doesn't make it faster, > >> Faster than what? > > Faster than an equivalent non-concurrent program. It'd also be nice > if performance was comparable lock-based implementation. > >> Are you considering using STM just to make otherwise pure code run in >> parallel on multiple cores? > > No, I have a complex structure that must be updated in non-predictable > ways. That's what STM is for, no? > > -k > -- > If I haven't seen further, it is by standing in the footprints of giants > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From briqueabraque at yahoo.com Tue Nov 18 02:25:03 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Tue Nov 18 02:19:24 2008 Subject: [Haskell-cafe] Re: Type question in instance of a class In-Reply-To: <6cf91caa0811171507h5477df33xd36418a9199a7db7@mail.gmail.com> References: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> <6cf91caa0811171507h5477df33xd36418a9199a7db7@mail.gmail.com> Message-ID: > Perhaps you want something like: > > class Complex r c | c -> r > where makeComplex :: r -> r -> c > realPart :: c -> r > imagPart :: c -> r > > data ComplexNumber t = CN t t > instance Complex t (ComplexNumber t) > where makeComplex = CN > realPart (CN r _) = r > imagPart (CN _ i) = i > > newtype ComplexWithDouble = CWD (ComplexNumber Double) > deriving (Complex Double) > > Having the parameters "backwards" is somewhat annoying, I suppose, but > it's unavoidable if you're hoping to use generalized newtype deriving > I believe. > Great! Actually, I would never imagine that (ComplexNumber Double) would yield a class with a single type variable... What is the logic behind that? I know about kinds (of types). Do classes have "kinds" of their own? Thanks, Maur?cio From ryani.spam at gmail.com Tue Nov 18 02:39:15 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Nov 18 02:33:25 2008 Subject: [Haskell-cafe] Re: OOPer? In-Reply-To: <3e1162e60811171236o991d635h2aeb6509566b1c9d@mail.gmail.com> References: <177953502.20081117004901@gmail.com> <3e1162e60811171236o991d635h2aeb6509566b1c9d@mail.gmail.com> Message-ID: <2f9b2d30811172339u9c4e8e4j1e4cf37ba3595a66@mail.gmail.com> David, I had to bring up a parenthetical from your message because I think it is often a point of confusion: 2008/11/17 David Leimbach : > (Would it then be fair to equate a Haskell class to a Java Interface, but not > to a Java class?) This is a dangerous direction to go, because while there are some analogies, going this direction leads to many mistakes. A typeclass is similar to an interface, in that it defines the operations on some object, and you can call functions that use that typeclass polymorphically over any instance. But in the OOP model, interfaces are also a form of existential quantification. If I have an IPrintable object, I can put it on a list of IPrintables: > // psuedo-java: > List foo(List tail) > { > String x = "hello"; // assume String is an instance of IPrintable > return List.cons(x, tail); > } But in Haskell, this function doesn't typecheck: > foo :: Show a => [a] -> [a] > foo xs = "hello" : xs The type of "foo" says that its argument is a homogenous list of *some* instance of Show, but it doesn't specify which one. Of course, in Haskell you can make this work with existential types: > data AnyShow = forall a. Show a => ExistentialShow a > foo2 :: [AnyShow] -> [AnyShow] > foo2 xs = ExistentialShow "hello" : xs > foo3 :: Show a => [a] -> [AnyShow] > foo3 xs = foo2 (map ExistentialShow xs) There are a few other differences; for example, > poly :: Num a => a > poly = fromInteger 1 The person *calling* poly determines what instance of Num they want returned; in OOP, poly would have to be called with a "factory" as an argument that told it how to construct the instance of the Num interface that the caller wants. This generalizes to code that would be much more difficult to write in an OOP style; consider: > poly2 :: Num a => a -> a > poly2 x = x + 1 -- in Haskell, 1 here is implicitly 'fromInteger 1' This is surprisingly hard to write in an OOP language, and almost certainly uglier than the Haskell solution. Either the arguments to plus have to be polymorphic, which is really difficult, or you need a special version of every operator that takes an Integer instead of the class in question, or you need some way to query the class for a factory which builds an instance of the class. In Haskell, (+) specifies that the arguments must be the same type, unlike the OOP solution where one argument is given privledged status as the method receiver. -- ryan From briqueabraque at yahoo.com Tue Nov 18 03:01:06 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Tue Nov 18 02:55:32 2008 Subject: [Haskell-cafe] Re: Type question in instance of a class In-Reply-To: <10610220603.20081117215503@gmail.com> References: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> <10610220603.20081117215503@gmail.com> Message-ID: > >> (...) One way to code this would be to use functional dependencies: > >> > >> class MyClass r s | r -> s where function :: r -> s > >> One additional problem is that I (believe I) need that my class takes >> just one type > > FDs with just one type parameter are called ATs :) > > (FDs = functional dependencies, ATs is a new feature of ghc 6.8/6.10) Sorry for asking, but I tried to read 6.10 extension documentation in user's guide, as well as release notes for 6.10 and 6.8, and could not figure out what exactly are ATs. Can you give me a direction? Thanks, Maur?cio From patperry at stanford.edu Tue Nov 18 04:00:01 2008 From: patperry at stanford.edu (Patrick Perry) Date: Tue Nov 18 03:54:16 2008 Subject: [Haskell-cafe] Re: Statically dimension-checked hmatrix In-Reply-To: <20081118073336.74A783243AD@www.haskell.org> References: <20081118073336.74A783243AD@www.haskell.org> Message-ID: <2E550391-505E-4C36-A73F-091203FD7045@stanford.edu> > What is the situation regarding statically dimension-checked linear > algebra libraries? It seems that Frederik Eaton was working on one in > 2006 (see the paper "Statically typed linear algebra in Haskell"), and > he produced the Vectro library from this, based on GSLHaskell. > > Are there any more recent efforts into this, particularly using the > new TFs? If not, I might have a go at it, as a thin wrapper for > hmatrix. The BLAS bindings I wrote use phantom types to make sure the dimensions are consistent. See, for example the functions to get row and column views of a matrix: http://hackage.haskell.org/packages/archive/blas/0.6/doc/html/Data-Matrix-Dense-Class.html#v%3ArowViews Also, the multiplication routines: http://hackage.haskell.org/packages/archive/blas/0.6/doc/html/BLAS-Matrix-Immutable.html I've found that phantom types are a good trade off: they provide enough type safety to catch common mistakes without being too much of a hassle to use. Another benefit (which I didn't anticipate) is that they help a *lot* with documentation. I'm skeptical of value that comes from stronger typing. At some point the types become too much of a hassle to be worth using. Even phantom types get in the way sometimes and require use of either GADTs, unsafeCoerce, or both, which is annoying. I'd be interested to hear about any developments you make in this area. Patrick p.s. If you're interested in trying it out, the version of blas on hackage doesn't compile with ghc-6.10.1, but the version in the darcs repository at http://stat.stanford.edu/~patperry/code/blas does. From semanticphilosopher at googlemail.com Tue Nov 18 04:12:15 2008 From: semanticphilosopher at googlemail.com (Neil Davies) Date: Tue Nov 18 04:06:30 2008 Subject: [Haskell-cafe] Proof of a multi-threaded application In-Reply-To: <877i71ils0.fsf@malde.org> References: <49214FCA.8060004@epfl.ch> <7ca3f0160811170452v1d405933qf87e6129865c2e89@mail.gmail.com> <87wsf2jyf1.fsf@malde.org> <9A015D433594EA478964C5B34AF3179B0247D069@ntsydexm06.pc.internal.macquarie.com> <877i71ils0.fsf@malde.org> Message-ID: Ketil You may not be asking the right question here. Your final system's performance is going to be influenced far more by your algorithm for updating than by STM (or any other concurrency primitive's) performance. Others have already mentioned the granularity of locking - but that one of the performance design decisions that you need to quantify. The relative merits of various approaches are going to come down to issues such as * given that you have a lock what is the cost of locking (in term of the lack of forward progress) * how often will you have to pay this cost (that will be application / data dependent) * given you use STM, what is the (differential) cost of the underlying housekeeping (depends what processing is with the 'atomically') * what is the likelihood that you will have to undo stuff (represents the same cost as the lack of forward progress). So the answer which is better, as it always is, will be - it depends Welcome to the wonderful world of performance engineering. The answer you seek is tractable - but will require more analysis. Neil On 18 Nov 2008, at 06:35, Ketil Malde wrote: > "Tim Docker" writes: > >>> My apologies for side-tracking, but does anybody have performance >>> numbers for STM? I have an application waiting to be written using >>> STM, boldly parallelizing where no man has parallelized before, but >>> if it doesn't make it faster, > >> Faster than what? > > Faster than an equivalent non-concurrent program. It'd also be nice > if performance was comparable lock-based implementation. > >> Are you considering using STM just to make otherwise pure code run in >> parallel on multiple cores? > > No, I have a complex structure that must be updated in non-predictable > ways. That's what STM is for, no? > > -k > -- > If I haven't seen further, it is by standing in the footprints of > giants > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From reiner.pope at gmail.com Tue Nov 18 04:38:10 2008 From: reiner.pope at gmail.com (Reiner Pope) Date: Tue Nov 18 04:32:20 2008 Subject: [Haskell-cafe] Re: Type question in instance of a class In-Reply-To: References: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> <10610220603.20081117215503@gmail.com> Message-ID: <4cf038ee0811180138m19ec6539ha645c02948502dd5@mail.gmail.com> ATs are "Associated Types", aka Type Families. They can be found in the GHC 6.10 manual here: http://haskell.org/ghc/docs/6.10.1/html/users_guide/type-families.html As a starting point, you might want to try something like: class Complex c where type RealType c realPart :: c -> RealType c imagPart :: c -> RealType c Cheers, Reiner On Tue, Nov 18, 2008 at 7:01 PM, Maur??cio wrote: >> >> (...) One way to code this would be to use functional dependencies: >> >> >> >> class MyClass r s | r -> s where function :: r -> s >> >>> One additional problem is that I (believe I) need that my class takes >>> just one type >> >> FDs with just one type parameter are called ATs :) >> >> (FDs = functional dependencies, ATs is a new feature of ghc 6.8/6.10) > > > Sorry for asking, but I tried to read 6.10 extension documentation > in user's guide, as well as release notes for 6.10 and 6.8, and > could not figure out what exactly are ATs. Can you give me a direction? > > Thanks, > Maur?cio > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jason.dusek at gmail.com Tue Nov 18 04:48:11 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Tue Nov 18 04:42:20 2008 Subject: [Haskell-cafe] Cabal and more than one version Message-ID: <42784f260811180148v7c48ed46p18132f44a377f8bf@mail.gmail.com> I'd like to be able to do something like: if (template-haskell < 2.3) cpp-options: -D TH_THE_YOUNGER else cpp-options: -D TH_THE_ELDER I guess this kind of thing is not possible at present? -- _jsn From g9ks157k at acme.softbase.org Tue Nov 18 05:01:14 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Nov 18 04:55:24 2008 Subject: [Haskell-cafe] GHC 6.10.1 and cabal[-install] Message-ID: <200811181101.14630.g9ks157k@acme.softbase.org> Hello, I installed GHC 6.10.1 today and expected it to contain the cabal command line utility. Unfortunately, this was not the case. Where can I download it? How do I install and configure it so that it is integrated best with GHC?6.10.1? For example, should cabal use some directory in the GHC tree to place compiled packages in? still links to cabal-install for a convenient way for installing packages. I thought that cabal-install is outdated. Isn?t it? Generally, Cabal info and documentation ist too hard to find on the web, in my opinion. Best wishes, Wolfgang From ketil at malde.org Tue Nov 18 05:04:13 2008 From: ketil at malde.org (Ketil Malde) Date: Tue Nov 18 04:58:23 2008 Subject: [Haskell-cafe] Proof of a multi-threaded application In-Reply-To: (Neil Davies's message of "Tue\, 18 Nov 2008 09\:12\:15 +0000") References: <49214FCA.8060004@epfl.ch> <7ca3f0160811170452v1d405933qf87e6129865c2e89@mail.gmail.com> <87wsf2jyf1.fsf@malde.org> <9A015D433594EA478964C5B34AF3179B0247D069@ntsydexm06.pc.internal.macquarie.com> <877i71ils0.fsf@malde.org> Message-ID: <87skppgxk2.fsf@malde.org> Neil Davies writes: > You may not be asking the right question here. Your final system's > performance is going to be influenced far more by your algorithm for > updating than by STM (or any other concurrency primitive's) > performance. I may not be asking the right question, but I am happy about the answer, including yours :-) I think STM is semantically the right tool for the (my) job, but for it to be useful, the implementation must not be the limiting factor. I.e running on n+1 CPUs should be measurably faster than running on n, at least up to n=8, and preferably more. With the assuming I can get enough parallelism and avoiding too many rollbacks, of course. > Others have already mentioned the granularity of locking - but that > one of the performance design decisions that you need to quantify. Yes. Fine grained - I'm thinking a large Array of TVars. (If you only have a single TVar, it might as well be an MVar, no?) -k -- If I haven't seen further, it is by standing in the footprints of giants From haskellmail at gmail.com Tue Nov 18 05:37:36 2008 From: haskellmail at gmail.com (kenny lu) Date: Tue Nov 18 05:31:46 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell Message-ID: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: dict.tgz Type: application/x-gzip Size: 2292 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081118/994c4552/dict.bin From jason.dusek at gmail.com Tue Nov 18 05:43:35 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Tue Nov 18 05:37:45 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> Message-ID: <42784f260811180243p590afcacie0455017e489b08c@mail.gmail.com> Did you use Unicode in Python? -- _jsn From bulat.ziganshin at gmail.com Tue Nov 18 05:54:51 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 18 05:49:17 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> Message-ID: <707924593.20081118135451@gmail.com> Hello kenny, Tuesday, November 18, 2008, 1:37:36 PM, you wrote: > The above number shows that my implementations of python style > dictionary? are space/time in-efficient as compared to python. thanks, interesting code 1. why you think that your code should be faster? pythob implementation is probably written in C ince it's one of its core data structures 2. you can solve IntMap problem by storing list of values with the same hash in tree's nodes -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From tobias.bexelius at avalanchestudios.se Tue Nov 18 06:12:20 2008 From: tobias.bexelius at avalanchestudios.se (Tobias Bexelius) Date: Tue Nov 18 06:06:31 2008 Subject: [Haskell-cafe] GHC 6.10.1 and cabal[-install] In-Reply-To: <200811181101.14630.g9ks157k@acme.softbase.org> References: <200811181101.14630.g9ks157k@acme.softbase.org> Message-ID: <698E8783CC407F4EB0DC9E994B6D4540D4BD16@nut.avalanchestudios.se> Hi, I used the cabal-install on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cabal-install In order to install it you will need these two packages first: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP-3001.1.4 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/zlib-0.5.0.0 For each package (starting with the last two of course), run: > runghc Setup configure > runghc Setup build > runghc Setup install Once its all done, you can instead use >cabal install x to install package x, and don't need to care about dependencies anymore. And theres nothing else you need to do in order to integrate it with ghc either... /Tobias -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Wolfgang Jeltsch Sent: den 18 november 2008 11:01 To: haskell-cafe@haskell.org Subject: [Haskell-cafe] GHC 6.10.1 and cabal[-install] Hello, I installed GHC 6.10.1 today and expected it to contain the cabal command line utility. Unfortunately, this was not the case. Where can I download it? How do I install and configure it so that it is integrated best with GHC?6.10.1? For example, should cabal use some directory in the GHC tree to place compiled packages in? still links to cabal-install for a convenient way for installing packages. I thought that cabal-install is outdated. Isn't it? Generally, Cabal info and documentation ist too hard to find on the web, in my opinion. Best wishes, Wolfgang _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe From haskellmail at gmail.com Tue Nov 18 06:30:16 2008 From: haskellmail at gmail.com (kenny lu) Date: Tue Nov 18 06:24:25 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <42784f260811180243p590afcacie0455017e489b08c@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <42784f260811180243p590afcacie0455017e489b08c@mail.gmail.com> Message-ID: <90bba1dc0811180330m19a3dae3s3e50f318e143b4ef@mail.gmail.com> No I do not consider unicode in these implementations. On Tue, Nov 18, 2008 at 6:43 PM, Jason Dusek wrote: > Did you use Unicode in Python? > > -- > _jsn > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081118/f833b733/attachment.htm From claus.reinke at talk21.com Tue Nov 18 06:33:25 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Nov 18 06:27:39 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> Message-ID: > main :: IO () > main = do { content <- readFile "in.txt" > ; let -- change this following type annotation > -- to change different type of the dictionary > -- dict :: DM.Map S.ByteString Int > -- dict :: IM.IntMap Int > dict :: Trie Int > dict = fromList (map parse_a_line (lines content)) > .. > where parse_a_line :: String -> (Key,Int) > parse_a_line line = case words line of > [key,val] -> (key,read val) > _ -> error " parse error. " Maps tend to be strict in their keys, but not in their values. You might be storing a lot of thunks with unparsed Strings instead of plain Int values. Something like this might make a difference wrt memory usage: [key,val] -> ((,) key) $! (read val) Hth, Claus > Here is a comparison of memory usage > > Map : 345 MB > IntMap : 146 MB > Trie : 282 MB > Python : 94 MB From haskellmail at gmail.com Tue Nov 18 06:34:25 2008 From: haskellmail at gmail.com (kenny lu) Date: Tue Nov 18 06:28:34 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <707924593.20081118135451@gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <707924593.20081118135451@gmail.com> Message-ID: <90bba1dc0811180334n1abc1cc8rc33dfcbf3eca0fbf@mail.gmail.com> Hi Bulat, > 1. why you think that your code should be faster? pythob > implementation is probably written in C ince it's one of its core data > structures > I am not hoping that my code should be faster, but at least not as slow as what it gets. Basically I am looking for an implementation which is close to the one in python. > > 2. you can solve IntMap problem by storing list of values with the > same hash in tree's nodes > Yeah, that would probably speed up the building time of the dictionary. However, storing the list of values in the tree nodes requires storing their original keys, so that it maintains the one-key-to-one-value semantics. This would takes up more space compared to the Trie approach. Regards, Kenny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081118/bcbe0ef9/attachment.htm From rendel at daimi.au.dk Tue Nov 18 06:46:47 2008 From: rendel at daimi.au.dk (Tillmann Rendel) Date: Tue Nov 18 06:41:05 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> Message-ID: <4922AB27.8030602@daimi.au.dk> kenny lu wrote: > Internally, python dictionary is implemented using hash table. > > My first attempt is to use Data.HashTable. However it was immediately > abandoned, as I realize the memory usage is unreasonably huge. Why should a Haskell hash table need more memory then a Python hash table? I've heard that Data.HashTable is bad, so maybe writing a good one could be an option. > Python dictionary allows for update. e.g. the statement > d['a'] = 3 > changes the value pointed by 'a' from 1 to 3. I understand "changes" in the sense of an destructive update: The hash table stays the same (in terms of "object identity"), but the content of the memory cell storing the value of d['a'] is changed in place. That means that the old hash table, with d['a'] == 1, doesn't exist anymore. > -- the Dict type class > class Dict d k v | d -> k v where > empty :: d > insert :: k -> v -> d -> d > lookup :: k -> d -> Maybe v > update :: k -> v -> d -> d But here you want to create a new d, e.g. a whole new hash table, which contains mostly the same content, but one memory cell different. The old hash table still exists in memory. That is a totally different operation which is quite likely to need more memory. Tillmann From bulat.ziganshin at gmail.com Tue Nov 18 06:48:56 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 18 06:54:36 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <90bba1dc0811180334n1abc1cc8rc33dfcbf3eca0fbf@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <707924593.20081118135451@gmail.com> <90bba1dc0811180334n1abc1cc8rc33dfcbf3eca0fbf@mail.gmail.com> Message-ID: <266563833.20081118144856@gmail.com> Hello kenny, Tuesday, November 18, 2008, 2:34:25 PM, you wrote: > I am not hoping that my code should be faster, but at least not as slow as what it gets. > Basically I am looking for an implementation which is close to the one in python. well, if haskell will allow to produce code not slower than C, it will be world's best language :) unfortunately, you should pay a lot for it's elegance -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From gtener at gmail.com Tue Nov 18 07:01:56 2008 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Tue Nov 18 06:56:06 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> Message-ID: <220e47b40811180401k24c4b61do15ab3a0e6be0621f@mail.gmail.com> 2008/11/18 kenny lu : > Dear all, > > I am trying to implement the python-style dictionary in Haskell. > > Python dictionary is a data structure that maps one key to one value. > For instance, a python dictionary > d = {'a':1, 'b':2 } > maps key 'a' to 1, 'b' to 2. > Python dictionary allows for update. e.g. the statement > d['a'] = 3 > changes the value pointed by 'a' from 1 to 3. > > Internally, python dictionary is implemented using hash table. > > My first attempt is to use Data.HashTable. However it was immediately > abandoned, as I realize the memory usage is unreasonably huge. > > ... > > I tested all three implementations by building a dictionary of size 1000000. > The result shows that the Map and the Trie approaches handle collision well, > but > the IntMap approach does not. > > > Here is a comparison of memory usage > > Map : 345 MB > IntMap : 146 MB > Trie : 282 MB > Python : 94 MB > > Here is a comparison of execution time (on an intel dual core 2.0G) > > Map: 26 sec > IntMap: 9 sec > Trie: 12 sec > Python: 2.24 sec > > > The above number shows that my implementations of python style dictionary > are space/time in-efficient as compared to python. > > Can some one point out what's wrong with my implementations? > First of all, you use Strings. That's a very bad thing when you care about memory restrictions. Fire up ghci type something like this: > let aas = replicate (1024*1024*10) 'a' > -- 22 Mb memory usage > length aas > 10485760 > -- 270 Mb memory usage 10 Mb string caused as much as 250 Mb increase in ghci's memory consumption. My guess? Use hashtables with ByteStrings. I rewrote part of your code. Results are quite promising. Haskell: 121 Mb total memory in use INIT time 0.02s ( 0.00s elapsed) MUT time 0.84s ( 1.00s elapsed) GC time 1.97s ( 2.02s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 2.83s ( 3.02s elapsed) %GC time 69.6% (66.8% elapsed) Python: $ time python dict.py 256 real 0m2.278s user 0m2.233s sys 0m0.078s memory: 101 Mb (as reported by Windows' Task Manager). The code: --- cut --- import qualified Data.ByteString.Lazy.Char8 as BS import Data.Int import Data.Bits (...) parse_a_line_BS :: BS.ByteString -> (BS.ByteString,Int) parse_a_line_BS line = case BS.words line of [key,val] -> (key,(read . BS.unpack) val) _ -> error " parse error. " main :: IO () main = do dict <- HT.new (==) hashByteString indata <- (map parse_a_line_BS `fmap` BS.lines `fmap` BS.readFile "in.txt") mapM_ (\ (k,v) -> HT.insert dict k v) indata HT.lookup dict (BS.pack "key256") >>= \v -> case v of Just vv -> putStrLn (show vv) Nothing -> putStrLn ("Not found") -- derived from Data.HashTable.hashString hashByteString :: BS.ByteString -> Int32 hashByteString = BS.foldl' f golden where f m c = fromIntegral (ord c) * magic + hashInt32 m magic = 0xdeadbeef hashInt32 :: Int32 -> Int32 hashInt32 x = mulHi x golden + x mulHi :: Int32 -> Int32 -> Int32 mulHi a b = fromIntegral (r `shiftR` 32) where r :: Int64 r = fromIntegral a * fromIntegral b golden :: Int32 golden = 1013904242 -- = round ((sqrt 5 - 1) * 2^32) :: Int32 --- cut --- I had to rewrite hashString to work for ByteStrings - basically it's just using different foldl'. All best Christopher Skrz?tnicki From bulat.ziganshin at gmail.com Tue Nov 18 07:03:01 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 18 06:57:52 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <4922AB27.8030602@daimi.au.dk> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <4922AB27.8030602@daimi.au.dk> Message-ID: <676357923.20081118150301@gmail.com> Hello Tillmann, Tuesday, November 18, 2008, 2:46:47 PM, you wrote: > Why should a Haskell hash table need more memory then a Python hash > table? I've heard that Data.HashTable is bad, so maybe writing a good > one could be an option. about Data.HashTable: it uses one huge array to store all the entries. the catch is that GC need to scan entire array on every (major) GC. using array of hashtables may improve situation a lot plus check GC times for every version: +RTS -Soutfile -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From semanticphilosopher at googlemail.com Tue Nov 18 07:13:03 2008 From: semanticphilosopher at googlemail.com (Neil Davies) Date: Tue Nov 18 07:07:16 2008 Subject: [Haskell-cafe] Proof of a multi-threaded application In-Reply-To: <87skppgxk2.fsf@malde.org> References: <49214FCA.8060004@epfl.ch> <7ca3f0160811170452v1d405933qf87e6129865c2e89@mail.gmail.com> <87wsf2jyf1.fsf@malde.org> <9A015D433594EA478964C5B34AF3179B0247D069@ntsydexm06.pc.internal.macquarie.com> <877i71ils0.fsf@malde.org> <87skppgxk2.fsf@malde.org> Message-ID: <562EEDA7-583B-463A-872D-499D6B6FD7BD@gmail.com> On 18 Nov 2008, at 10:04, Ketil Malde wrote: > Neil Davies writes: > >> You may not be asking the right question here. Your final system's >> performance is going to be influenced far more by your algorithm for >> updating than by STM (or any other concurrency primitive's) >> performance. > > I may not be asking the right question, but I am happy about the > answer, including yours :-) > > I think STM is semantically the right tool for the (my) job, but for > it to be useful, the implementation must not be the limiting factor. > I.e running on n+1 CPUs should be measurably faster than running on n, > at least up to n=8, and preferably more. More detailed questions: how complex is the mutual exclusion block? If it is well known now and not likely to change you can implement several ways and work out any extra overhead (run it lot) against the other approaches. Nothing like a quick benchmark. Otherwise stick with STM (its composable after all). > With the assuming I can get enough parallelism and avoiding too many > rollbacks, of course. Its not the parallelism that is the issue here, it is the locality of reference. If you have data that is likely to be widely spread amongst all the possible mutual exclusion blocks then you are on to a winner. If your data is clustered and likely to hit the same 'block' then, whatever you do, your scalability is scuppered. Also, consider how much concurrency you've got, not just the parallelism. You need enough concurrency to exploit the parallelism but not too much more - too much more can start creating contention for the mutual exclusion blocks that would not have existed at less concurrency. >> Others have already mentioned the granularity of locking - but that >> one of the performance design decisions that you need to quantify. > > Yes. Fine grained - I'm thinking a large Array of TVars. (If you > only have a single TVar, it might as well be an MVar, no?) What do those TVars contain? how many of them are being updated atomically? > -k > -- > If I haven't seen further, it is by standing in the footprints of > giants Neil From ryani.spam at gmail.com Tue Nov 18 07:27:14 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Nov 18 07:21:23 2008 Subject: [Haskell-cafe] Proof of a multi-threaded application In-Reply-To: <87skppgxk2.fsf@malde.org> References: <49214FCA.8060004@epfl.ch> <7ca3f0160811170452v1d405933qf87e6129865c2e89@mail.gmail.com> <87wsf2jyf1.fsf@malde.org> <9A015D433594EA478964C5B34AF3179B0247D069@ntsydexm06.pc.internal.macquarie.com> <877i71ils0.fsf@malde.org> <87skppgxk2.fsf@malde.org> Message-ID: <2f9b2d30811180427j7980692h8332bcb833bf5ad7@mail.gmail.com> On Tue, Nov 18, 2008 at 2:04 AM, Ketil Malde wrote: > Yes. Fine grained - I'm thinking a large Array of TVars. (If you > only have a single TVar, it might as well be an MVar, no?) With only one I think that IORef + atomicModifyIORef might even be better! :) -- ryan From rendel at daimi.au.dk Tue Nov 18 07:27:06 2008 From: rendel at daimi.au.dk (Tillmann Rendel) Date: Tue Nov 18 07:21:32 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <4922AB27.8030602@daimi.au.dk> Message-ID: <4922B49A.5030209@daimi.au.dk> Hello Alberto, I cc this to haskell-cafe again. Alberto G. Corona wrote: > Not so much memory, because data is referentially transparent, the new Map > can point to whole subtrees of the old map that stay the same. is similar > than when a new list is created by prefixing a new element from a old list > ys= x:xs. ys is not at all a fresh copy, but x plus a pointer to the head > of xs. this is the only new data that is needed to create ys. You could just as well compare with appending a new element to the end of the list, which needs a complete copy of the list structure to be made. One has to look more closely to see which case it is here. More specifically, I do not see how this sharing of substructures could be employed in the implementation of hash tables, which rely on O(1) random access into arrays. Tillmann From agocorona at gmail.com Tue Nov 18 07:41:49 2008 From: agocorona at gmail.com (Alberto G. Corona ) Date: Tue Nov 18 07:36:00 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <4922B49A.5030209@daimi.au.dk> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <4922AB27.8030602@daimi.au.dk> <4922B49A.5030209@daimi.au.dk> Message-ID: The most balanced case may be the insertion of a element in the middle of a list, but this is far worst than to insert an element in a particular branch of a tree ( it needs an average of list-lenght/2 element creations while in a tree needs only (average-branch-length)/2) I refer to Maps, because Hashtables, in the IO monad, are mutable. by the way let map2= map1 takes 0 bytes of memory And both do not share side effects, while creating two copies of a hastable to avoid side effects between them needs 2 * size. 2008/11/18 Tillmann Rendel > Hello Alberto, > > I cc this to haskell-cafe again. > > Alberto G. Corona wrote: > >> Not so much memory, because data is referentially transparent, the new Map >> can point to whole subtrees of the old map that stay the same. is similar >> than when a new list is created by prefixing a new element from a old >> list >> ys= x:xs. ys is not at all a fresh copy, but x plus a pointer to the >> head >> of xs. this is the only new data that is needed to create ys. >> > > You could just as well compare with appending a new element to the end of > the list, which needs a complete copy of the list structure to be made. One > has to look more closely to see which case it is here. > > More specifically, I do not see how this sharing of substructures could be > employed in the implementation of hash tables, which rely on O(1) random > access into arrays. > > Tillmann > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081118/48474a3e/attachment-0001.htm From g9ks157k at acme.softbase.org Tue Nov 18 08:23:12 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Nov 18 08:17:20 2008 Subject: [Haskell-cafe] GHC 6.10.1 and cabal[-install] In-Reply-To: <200811181101.14630.g9ks157k@acme.softbase.org> References: <200811181101.14630.g9ks157k@acme.softbase.org> Message-ID: <200811181423.12306.g9ks157k@acme.softbase.org> Am Dienstag, 18. November 2008 11:01 schrieb Wolfgang Jeltsch: > Hello, > > I installed GHC 6.10.1 today and expected it to contain the cabal command > line utility. Unfortunately, this was not the case. Where can I download > it? Meanwhile, I found out that the package cabal-install includes the cabal command. On the other hand I thought that there was a now deprecated command line tool named cabal-install. I find this a bit confusing. > How do I install and configure it so that it is integrated best with > GHC?6.10.1? For example, should cabal use some directory in the GHC tree > to place compiled packages in? Cabal wants to place package info in $HOME/.cabal. However, I want to install packages globally with sudo. So I want to have a global package cache. Is there a common directory to be used for that or is cabal[-install] only for per-user installations? Well, there is the --global option but it is apparently only for registering packages globally. Does it change the destination directory for the installed packages too? If yes, to what directory? Is the default --global or --user? Sorry, but I cannot find the answers to this in the docs and I don?t want to mess up my file system. Best wishes, Wolfgang From jmaessen at alum.mit.edu Tue Nov 18 08:33:31 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Tue Nov 18 08:27:45 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <676357923.20081118150301@gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <4922AB27.8030602@daimi.au.dk> <676357923.20081118150301@gmail.com> Message-ID: <81B42C2D-2EAC-47DD-93BE-76CB634E65E8@alum.mit.edu> On Nov 18, 2008, at 7:03 AM, Bulat Ziganshin wrote: > Hello Tillmann, > > Tuesday, November 18, 2008, 2:46:47 PM, you wrote: > >> Why should a Haskell hash table need more memory then a Python hash >> table? I've heard that Data.HashTable is bad, so maybe writing a good >> one could be an option. > > about Data.HashTable: it uses one huge array to store all the entries. > the catch is that GC need to scan entire array on every (major) GC. Actually, the scan on every major (full) GC is unavoidable. What *can* be avoided is a scan on every *minor* GC that occurs after an update. I forget what the exact strategy is here, but I know that one write used to cause the entire array to be re-scanned; what I don't remember is when/if the array transitions back to a state where it isn't being scanned by minor GC anymore. > using array of hashtables may improve situation a lot Yes, this would be worth trying. Understanding the current GC strategy would make it easier to make the right tradeoffs here; we expect n insertions will touch O(n) subtables, so repeated insertion will make life worse if we're not careful. -Jan-Willem Maessen > plus check GC times for every version: +RTS -Soutfile > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From g9ks157k at acme.softbase.org Tue Nov 18 09:01:00 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Nov 18 08:55:16 2008 Subject: [Haskell-cafe] portable arrow instances Message-ID: <200811181501.00542.g9ks157k@acme.softbase.org> Hello, how do I make a library work with both GHC 6.8 and GHC 6.10? According to , I should change all my Arrow instances but then they don?t work with GHC 6.8 anymore, do they? Or is the solution to force GHC 6.8 users to use base-4.0.0.0? Best wishes, Wolfgang From ross at soi.city.ac.uk Tue Nov 18 09:19:39 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Nov 18 09:13:50 2008 Subject: [Haskell-cafe] portable arrow instances In-Reply-To: <200811181501.00542.g9ks157k@acme.softbase.org> References: <200811181501.00542.g9ks157k@acme.softbase.org> Message-ID: <20081118141938.GA5900@soi.city.ac.uk> On Tue, Nov 18, 2008 at 03:01:00PM +0100, Wolfgang Jeltsch wrote: > how do I make a library work with both GHC 6.8 and GHC 6.10? According to > , I > should change all my Arrow instances but then they don't work with GHC 6.8 > anymore, do they? Or is the solution to force GHC 6.8 users to use > base-4.0.0.0? GHC 6.8 users can't use base-4. I think it's either two versions or cpp. From hthiel.char at zonnet.nl Tue Nov 18 10:03:24 2008 From: hthiel.char at zonnet.nl (Hans van Thiel) Date: Tue Nov 18 09:57:08 2008 Subject: [Haskell-cafe] Proof of a multi-threaded application In-Reply-To: <7ca3f0160811170452v1d405933qf87e6129865c2e89@mail.gmail.com> References: <49214FCA.8060004@epfl.ch> <7ca3f0160811170452v1d405933qf87e6129865c2e89@mail.gmail.com> Message-ID: <1227020604.3046.18.camel@dhcppc0> On Mon, 2008-11-17 at 05:52 -0700, Luke Palmer wrote: > On Mon, Nov 17, 2008 at 4:04 AM, Silviu ANDRICA wrote: > > Hello, > > I am very new to Haskell, this is my first day, and I wanted to know if it > > is possible to prove correctness of a multi-threaded application written in > > Haskell. > > Basically, I want to check that a multi-threaded implementation of an > > algorithm that detects cycles in a dynamically changing graph, actually > > detects the cycles. Also, the algorithm prevents previously detected cycles > > from happening by not allowing certain edges to be added. And I want to > > check that this property also holds. > > This is going to be difficult -- no matter what language you try to > prove it in. In Haskell you have a decent shot, I suppose, since you > could at least prove the pure bits correct without much fuss. > > The way I might try to approach this is to model your algorithm and > the dynamically changing graph together as a nondeterministic state > machine: a function of type State -> [State] (returning all the > possible "next steps" of the system). Then I would look for some > invariant that is preserved at each step, and prove its preservation. > > That is how you could prove your *algorithm* correct. But I suspect > there will be many difficulties proving that your implementation > corresponds to your algorithm. This is mostly because in the IO > monad, "anything goes"; i.e. the semantics are complex and mostly > unknown. You might make some progress by isolating a small portion of > the IO monad and assuming that it obeys some particular reasonable > nondeterministic semantics. But that will be a large, intuitive > assumption which will decrease the degree of certainty of your proof. > > If you implement your algorithm in terms of STM (one of Haskell's > flaunting points :-) rather than more traditional primitives (eg. > locks) you will have a better shot, since you can more easily show > that an invariant is kept before and after a transaction, without > having to fuss with the concurrency details inside where the invariant > is briefly broken. > > Concurrency is quite hard to reason about formally (no matter what > language it is in). Good luck! > > Luke > Yes, but if it's worth the effort you could do a formal verification, not of the code, but of a model with the Spin model checker. http://spinroot.com/spin/whatispin.html First you write a model in Promela (Process meta language) which looks a lot like C, but abstracts from (most of) the computations and instead concentrates on communication and coordination of non-deterministic processes. With Spin and the graphical interface XSpin (or the alternative JSpin) you can both simulate and verify your model. It finds deadlocks, you can write asserts, test liveness and you can even check claims in LTL (linear temporal logic) about execution paths. It's all open source and free. 'The Spin Model Checker', by Gerard Holzmann, is the reference, but there are several other books about Spin and its principles. Best Regards, Hans van Thiel From vanenkj at gmail.com Tue Nov 18 10:20:17 2008 From: vanenkj at gmail.com (John Van Enk) Date: Tue Nov 18 10:14:26 2008 Subject: [Haskell-cafe] Deploying a Binary Haskell Package Message-ID: This question isn't directly related to Haskell, but I figure some one might know here. I want to deploy an application. I could either: 1) Tell people how to download GHC, have them check out the repository, have them install all the needed hackage packages, ... or 2) Give them a setup.msi/exe I'm curious if any one has done this with a Haskell package. It seems that it's something that might make sense being integrated into Cabal (runhaskell Setup msi). Either way, has some one deployed a Haskell binary as a MSI package? /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081118/9f50ed76/attachment.htm From dons at galois.com Tue Nov 18 10:26:41 2008 From: dons at galois.com (Don Stewart) Date: Tue Nov 18 10:20:49 2008 Subject: [Haskell-cafe] Deploying a Binary Haskell Package In-Reply-To: References: Message-ID: <20081118152641.GB839@scytale.galois.com> vanenkj: > This question isn't directly related to Haskell, but I figure some one > might know here. > > I want to deploy an application. I could either: > 1) Tell people how to download GHC, have them check out the repository, > have them install all the needed hackage packages, ... > or > 2) Give them a setup.msi/exe > > I'm curious if any one has done this with a Haskell package. It seems that > it's something that might make sense being integrated into Cabal > (runhaskell Setup msi). > > Either way, has some one deployed a Haskell binary as a MSI package? > Yes, Galois has , using the windows installer builder (for binary Haskell blobs). -- Don From dons at galois.com Tue Nov 18 10:33:29 2008 From: dons at galois.com (Don Stewart) Date: Tue Nov 18 10:27:37 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> Message-ID: <20081118153329.GD839@scytale.galois.com> Which version of GHC and which version of the Data.ByteString library? There was an inlining bug related to Data.Map /Data.IntMap performance fixed between the 6.8.x release and the current bytestring release. In testing, Data.Map with strict bytestring keys matched the python (C implemented) dictionary, after I fixed the inlining for word lookups. You'll need to be using bytestring 0.9.1.x though. -- Don haskellmail: > Dear all, > > I am trying to implement the python-style dictionary in Haskell. > > Python dictionary is a data structure that maps one key to one value. > For instance, a python dictionary > d = {'a':1, 'b':2 } > maps key 'a' to 1, 'b' to 2. > Python dictionary allows for update. e.g. the statement > d['a'] = 3 > changes the value pointed by 'a' from 1 to 3. > > Internally, python dictionary is implemented using hash table. > > My first attempt is to use Data.HashTable. However it was immediately > abandoned, as I realize the memory usage is unreasonably huge. > > == SECOND ATTEMPT == > My second attempt is to use Data.Map > > {-# OPTIONS_GHC -fglasgow-exts #-} > module Main where > > import qualified Data.HashTable as HT > import qualified Data.IntMap as IM > import qualified Data.Map as DM > import qualified Data.ByteString.Char8 as S > import Data.Char > > -- the Dict type class > class Dict d k v | d -> k v where > empty :: d > insert :: k -> v -> d -> d > lookup :: k -> d -> Maybe v > update :: k -> v -> d -> d > > -- Let's use string as key > type Key = String > > -- insert key-value pairs into a dictionary > fromList :: Dict d k a => [(k,a)] -> d > fromList l = > foldl (\d (key,val) -> insert key val d) empty l > > instance Dict (DM.Map S.ByteString a) Key a where > empty = DM.empty > insert key val dm = > let packed_key = S.pack key > in DM.insert packed_key val dm > lookup key dm = > let packed_key = S.pack key > in DM.lookup packed_key dm > update key val dm = > let packed_key = S.pack key > in DM.update (\x -> Just val) packed_key dm > > Which kinda works, however since Map is implemented using a balanced tree, > therefore, > when as the dictionary grows, it takes a long time to insert new key-value > pair. > > == THIRD ATTEMPT == > My third attempt is to use Data.IntMap > > -- an implementation of Dict using IntMap > instance Dict (IM.IntMap a) Key a where > empty = IM.empty > insert key val im = > let int_key = fromIntegral (HT.hashString key) > in IM.insert int_key val im > lookup key im = > let int_key = fromIntegral (HT.hashString key) > in IM.lookup int_key im > update key val im = > let int_key = fromIntegral (HT.hashString key) > in IM.update (\x -> Just val) int_key im > > This implementation is faster than the Map approach, however this > implementation > can't handle collision well, two keys which are hashed into the same > integer will overwrite each other. > > == FOURTH ATTEMPT == > > My fourth implementation is to use Trie. The idea is to split a string (a > key) into > a list of 4-character chunks. Each chunk can be mapped into a 32-bit > integer without collision. > We then insert the value with this list of chunks into the Trie. > > -- an implementation of Dict using Trie > instance Dict (Trie a) Key a where > empty = emptyTrie > insert key val trie = > let key_chain = chain key > in insertTrie key_chain val trie > lookup key trie = > let key_chain = chain key > in lookupTrie key_chain trie > update key val trie = > let key_chain = chain key > in updateTrie key_chain val trie > > -- an auxillary function that "splits" string into small pieces, > -- 4 characters per piece, 4 chars = 32 bit > chain :: Key -> [Key] > chain k | length k > 4 = let (k',ks) = splitAt 4 k > in (k':chain ks) > | otherwise = [k] > > -- a collision-free hash function which turns four chars into Int32 > safehash :: [Char] -> Int > safehash cs | length cs > 4 = error "safehash failed." > | otherwise = > sum [ (ord c)*(256^i) | (c,i) <- zip cs [0..3] ] > > -- a trie datatype > data Trie a = Trie [a] (IM.IntMap (Trie a)) > > -- the empty trie > emptyTrie = Trie [] (IM.empty) > > -- insert value into the trie > insertTrie :: [String] -> a -> Trie a -> Trie a > insertTrie [] i (Trie is maps) = Trie (i:is) maps > insertTrie (word:words) i (Trie is maps) = > let key = safehash word > in case IM.lookup key maps of > { Just trie -> let trie' = insertTrie words i trie > maps' = IM.update (\x -> Just trie') key maps > in Trie is maps' > ; Nothing -> let trie = emptyTrie > trie' = insertTrie words i trie > maps' = IM.insert key trie' maps > in Trie is maps' > } > > -- lookup value from the trie > lookupTrie :: [String] -> Trie a -> Maybe a > lookupTrie [] (Trie vs _) = > case vs of > [] -> Nothing > (x:_) -> Just x > lookupTrie (word:words) (Trie is maps) = > let key = safehash word > in case IM.lookup key maps of > Just trie -> lookupTrie words trie > Nothing -> Nothing > > -- update the trie with the given value. > updateTrie :: [String] -> a -> Trie a -> Trie a > -- we only update the first value and leave the rest unchanged. > updateTrie [] y (Trie (x:xs) maps) = Trie (y:xs) maps > updateTrie (word:words) v (Trie is maps) = > let key = safehash word > in case IM.lookup key maps of > Just trie -> let trie' = updateTrie words v trie > maps' = IM.update (\x -> Just trie') key maps > in Trie is maps' > Nothing -> Trie is maps > > == BENCH MARK == > > I have a main function which builds a dictionary from a text file. > Each line of the file is a key-value pair separated by a space. > > e.g. > > key1 1 > key2 2 > ... > > main :: IO () > main = do { content <- readFile "in.txt" > ; let -- change this following type annotation > -- to change different type of the dictionary > -- dict :: DM.Map S.ByteString Int > -- dict :: IM.IntMap Int > dict :: Trie Int > dict = fromList (map parse_a_line (lines content)) > ; case Main.lookup "key256" dict of > { Just v -> putStrLn (show v) > ; Nothing -> putStrLn "Not found" > } > -- read a line here so that we can pause the program > -- and look at the memory usage. > ; v <- readLn > ; putStrLn v > } > where parse_a_line :: String -> (Key,Int) > parse_a_line line = case words line of > [key,val] -> (key,read val) > _ -> error " parse error. " > > I tested all three implementations by building a dictionary of size > 1000000. > The result shows that the Map and the Trie approaches handle collision > well, but > the IntMap approach does not. > > Here is a comparison of memory usage > > Map : 345 MB > IntMap : 146 MB > Trie : 282 MB > Python : 94 MB > > Here is a comparison of execution time (on an intel dual core 2.0G) > > Map: 26 sec > IntMap: 9 sec > Trie: 12 sec > Python: 2.24 sec > > The above number shows that my implementations of python style dictionary > are space/time in-efficient as compared to python. > > Can some one point out what's wrong with my implementations? > > I've attached my code in the tgz file. > > Cheers, > Kenny > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From haskellmail at gmail.com Tue Nov 18 10:36:21 2008 From: haskellmail at gmail.com (kenny lu) Date: Tue Nov 18 10:30:31 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <20081118153329.GD839@scytale.galois.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <20081118153329.GD839@scytale.galois.com> Message-ID: <90bba1dc0811180736r64ebce65pd35b64c92506a2b2@mail.gmail.com> Dear Don, I am using GHC 6.8.1 Regards, Kenny On Tue, Nov 18, 2008 at 11:33 PM, Don Stewart wrote: > Which version of GHC and which version of the Data.ByteString library? > There was an inlining bug related to Data.Map /Data.IntMap performance > fixed between the 6.8.x release and the current bytestring release. > > In testing, Data.Map with strict bytestring keys matched the python (C > implemented) dictionary, after I fixed the inlining for word lookups. > > You'll need to be using bytestring 0.9.1.x though. > > -- Don > > haskellmail: > > Dear all, > > > > I am trying to implement the python-style dictionary in Haskell. > > > > Python dictionary is a data structure that maps one key to one value. > > For instance, a python dictionary > > d = {'a':1, 'b':2 } > > maps key 'a' to 1, 'b' to 2. > > Python dictionary allows for update. e.g. the statement > > d['a'] = 3 > > changes the value pointed by 'a' from 1 to 3. > > > > Internally, python dictionary is implemented using hash table. > > > > My first attempt is to use Data.HashTable. However it was immediately > > abandoned, as I realize the memory usage is unreasonably huge. > > > > == SECOND ATTEMPT == > > My second attempt is to use Data.Map > > > > {-# OPTIONS_GHC -fglasgow-exts #-} > > module Main where > > > > import qualified Data.HashTable as HT > > import qualified Data.IntMap as IM > > import qualified Data.Map as DM > > import qualified Data.ByteString.Char8 as S > > import Data.Char > > > > -- the Dict type class > > class Dict d k v | d -> k v where > > empty :: d > > insert :: k -> v -> d -> d > > lookup :: k -> d -> Maybe v > > update :: k -> v -> d -> d > > > > -- Let's use string as key > > type Key = String > > > > -- insert key-value pairs into a dictionary > > fromList :: Dict d k a => [(k,a)] -> d > > fromList l = > > foldl (\d (key,val) -> insert key val d) empty l > > > > instance Dict (DM.Map S.ByteString a) Key a where > > empty = DM.empty > > insert key val dm = > > let packed_key = S.pack key > > in DM.insert packed_key val dm > > lookup key dm = > > let packed_key = S.pack key > > in DM.lookup packed_key dm > > update key val dm = > > let packed_key = S.pack key > > in DM.update (\x -> Just val) packed_key dm > > > > Which kinda works, however since Map is implemented using a balanced > tree, > > therefore, > > when as the dictionary grows, it takes a long time to insert new > key-value > > pair. > > > > == THIRD ATTEMPT == > > My third attempt is to use Data.IntMap > > > > -- an implementation of Dict using IntMap > > instance Dict (IM.IntMap a) Key a where > > empty = IM.empty > > insert key val im = > > let int_key = fromIntegral (HT.hashString key) > > in IM.insert int_key val im > > lookup key im = > > let int_key = fromIntegral (HT.hashString key) > > in IM.lookup int_key im > > update key val im = > > let int_key = fromIntegral (HT.hashString key) > > in IM.update (\x -> Just val) int_key im > > > > This implementation is faster than the Map approach, however this > > implementation > > can't handle collision well, two keys which are hashed into the same > > integer will overwrite each other. > > > > == FOURTH ATTEMPT == > > > > My fourth implementation is to use Trie. The idea is to split a string > (a > > key) into > > a list of 4-character chunks. Each chunk can be mapped into a 32-bit > > integer without collision. > > We then insert the value with this list of chunks into the Trie. > > > > -- an implementation of Dict using Trie > > instance Dict (Trie a) Key a where > > empty = emptyTrie > > insert key val trie = > > let key_chain = chain key > > in insertTrie key_chain val trie > > lookup key trie = > > let key_chain = chain key > > in lookupTrie key_chain trie > > update key val trie = > > let key_chain = chain key > > in updateTrie key_chain val trie > > > > -- an auxillary function that "splits" string into small pieces, > > -- 4 characters per piece, 4 chars = 32 bit > > chain :: Key -> [Key] > > chain k | length k > 4 = let (k',ks) = splitAt 4 k > > in (k':chain ks) > > | otherwise = [k] > > > > -- a collision-free hash function which turns four chars into Int32 > > safehash :: [Char] -> Int > > safehash cs | length cs > 4 = error "safehash failed." > > | otherwise = > > sum [ (ord c)*(256^i) | (c,i) <- zip cs [0..3] ] > > > > -- a trie datatype > > data Trie a = Trie [a] (IM.IntMap (Trie a)) > > > > -- the empty trie > > emptyTrie = Trie [] (IM.empty) > > > > -- insert value into the trie > > insertTrie :: [String] -> a -> Trie a -> Trie a > > insertTrie [] i (Trie is maps) = Trie (i:is) maps > > insertTrie (word:words) i (Trie is maps) = > > let key = safehash word > > in case IM.lookup key maps of > > { Just trie -> let trie' = insertTrie words i trie > > maps' = IM.update (\x -> Just trie') key maps > > in Trie is maps' > > ; Nothing -> let trie = emptyTrie > > trie' = insertTrie words i trie > > maps' = IM.insert key trie' maps > > in Trie is maps' > > } > > > > -- lookup value from the trie > > lookupTrie :: [String] -> Trie a -> Maybe a > > lookupTrie [] (Trie vs _) = > > case vs of > > [] -> Nothing > > (x:_) -> Just x > > lookupTrie (word:words) (Trie is maps) = > > let key = safehash word > > in case IM.lookup key maps of > > Just trie -> lookupTrie words trie > > Nothing -> Nothing > > > > -- update the trie with the given value. > > updateTrie :: [String] -> a -> Trie a -> Trie a > > -- we only update the first value and leave the rest unchanged. > > updateTrie [] y (Trie (x:xs) maps) = Trie (y:xs) maps > > updateTrie (word:words) v (Trie is maps) = > > let key = safehash word > > in case IM.lookup key maps of > > Just trie -> let trie' = updateTrie words v trie > > maps' = IM.update (\x -> Just trie') key maps > > in Trie is maps' > > Nothing -> Trie is maps > > > > == BENCH MARK == > > > > I have a main function which builds a dictionary from a text file. > > Each line of the file is a key-value pair separated by a space. > > > > e.g. > > > > key1 1 > > key2 2 > > ... > > > > main :: IO () > > main = do { content <- readFile "in.txt" > > ; let -- change this following type annotation > > -- to change different type of the dictionary > > -- dict :: DM.Map S.ByteString Int > > -- dict :: IM.IntMap Int > > dict :: Trie Int > > dict = fromList (map parse_a_line (lines content)) > > ; case Main.lookup "key256" dict of > > { Just v -> putStrLn (show v) > > ; Nothing -> putStrLn "Not found" > > } > > -- read a line here so that we can pause the program > > -- and look at the memory usage. > > ; v <- readLn > > ; putStrLn v > > } > > where parse_a_line :: String -> (Key,Int) > > parse_a_line line = case words line of > > [key,val] -> (key,read val) > > _ -> error " parse error. " > > > > I tested all three implementations by building a dictionary of size > > 1000000. > > The result shows that the Map and the Trie approaches handle collision > > well, but > > the IntMap approach does not. > > > > Here is a comparison of memory usage > > > > Map : 345 MB > > IntMap : 146 MB > > Trie : 282 MB > > Python : 94 MB > > > > Here is a comparison of execution time (on an intel dual core 2.0G) > > > > Map: 26 sec > > IntMap: 9 sec > > Trie: 12 sec > > Python: 2.24 sec > > > > The above number shows that my implementations of python style > dictionary > > are space/time in-efficient as compared to python. > > > > Can some one point out what's wrong with my implementations? > > > > I've attached my code in the tgz file. > > > > Cheers, > > Kenny > > > > _______________________________________________ > > 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/20081118/b029eb85/attachment.htm From dons at galois.com Tue Nov 18 10:44:05 2008 From: dons at galois.com (Don Stewart) Date: Tue Nov 18 10:38:13 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <90bba1dc0811180736r64ebce65pd35b64c92506a2b2@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <20081118153329.GD839@scytale.galois.com> <90bba1dc0811180736r64ebce65pd35b64c92506a2b2@mail.gmail.com> Message-ID: <20081118154405.GE839@scytale.galois.com> Great. Assuming you're following the advice to use bytestrings, please install the newest bytestring library version, here, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring Data.Map or Data.IntMap with bytestrings should be quite efficient. (or use a trie if more precision is needed) -- Don haskellmail: > Dear Don, > I am using GHC 6.8.1 > > Regards, > Kenny > > On Tue, Nov 18, 2008 at 11:33 PM, Don Stewart <[1]dons@galois.com> wrote: > > Which version of GHC and which version of the Data.ByteString library? > There was an inlining bug related to Data.Map /Data.IntMap performance > fixed between the 6.8.x release and the current bytestring release. > > In testing, Data.Map with strict bytestring keys matched the python (C > implemented) dictionary, after I fixed the inlining for word lookups. > > You'll need to be using bytestring 0.9.1.x though. > > -- Don > > haskellmail: > > Dear all, > > > > I am trying to implement the python-style dictionary in Haskell. > > > > Python dictionary is a data structure that maps one key to one > value. > > For instance, a python dictionary > > d = {'a':1, 'b':2 } > > maps key 'a' to 1, 'b' to 2. > > Python dictionary allows for update. e.g. the statement > > d['a'] = 3 > > changes the value pointed by 'a' from 1 to 3. > > > > Internally, python dictionary is implemented using hash table. > > > > My first attempt is to use Data.HashTable. However it was > immediately > > abandoned, as I realize the memory usage is unreasonably huge. > > > > == SECOND ATTEMPT == > > My second attempt is to use Data.Map > > > > {-# OPTIONS_GHC -fglasgow-exts #-} > > module Main where > > > > import qualified Data.HashTable as HT > > import qualified Data.IntMap as IM > > import qualified Data.Map as DM > > import qualified Data.ByteString.Char8 as S > > import Data.Char > > > > -- the Dict type class > > class Dict d k v | d -> k v where > > empty :: d > > insert :: k -> v -> d -> d > > lookup :: k -> d -> Maybe v > > update :: k -> v -> d -> d > > > > -- Let's use string as key > > type Key = String > > > > -- insert key-value pairs into a dictionary > > fromList :: Dict d k a => [(k,a)] -> d > > fromList l = > > foldl (\d (key,val) -> insert key val d) empty l > > > > instance Dict (DM.Map S.ByteString a) Key a where > > empty = DM.empty > > insert key val dm = > > let packed_key = S.pack key > > in DM.insert packed_key val dm > > lookup key dm = > > let packed_key = S.pack key > > in DM.lookup packed_key dm > > update key val dm = > > let packed_key = S.pack key > > in DM.update (\x -> Just val) packed_key dm > > > > Which kinda works, however since Map is implemented using a > balanced tree, > > therefore, > > when as the dictionary grows, it takes a long time to insert new > key-value > > pair. > > > > == THIRD ATTEMPT == > > My third attempt is to use Data.IntMap > > > > -- an implementation of Dict using IntMap > > instance Dict (IM.IntMap a) Key a where > > empty = IM.empty > > insert key val im = > > let int_key = fromIntegral (HT.hashString key) > > in IM.insert int_key val im > > lookup key im = > > let int_key = fromIntegral (HT.hashString key) > > in IM.lookup int_key im > > update key val im = > > let int_key = fromIntegral (HT.hashString key) > > in IM.update (\x -> Just val) int_key im > > > > This implementation is faster than the Map approach, however this > > implementation > > can't handle collision well, two keys which are hashed into the > same > > integer will overwrite each other. > > > > == FOURTH ATTEMPT == > > > > My fourth implementation is to use Trie. The idea is to split a > string (a > > key) into > > a list of 4-character chunks. Each chunk can be mapped into a > 32-bit > > integer without collision. > > We then insert the value with this list of chunks into the Trie. > > > > -- an implementation of Dict using Trie > > instance Dict (Trie a) Key a where > > empty = emptyTrie > > insert key val trie = > > let key_chain = chain key > > in insertTrie key_chain val trie > > lookup key trie = > > let key_chain = chain key > > in lookupTrie key_chain trie > > update key val trie = > > let key_chain = chain key > > in updateTrie key_chain val trie > > > > -- an auxillary function that "splits" string into small pieces, > > -- 4 characters per piece, 4 chars = 32 bit > > chain :: Key -> [Key] > > chain k | length k > 4 = let (k',ks) = splitAt 4 k > > in (k':chain ks) > > | otherwise = [k] > > > > -- a collision-free hash function which turns four chars into Int32 > > safehash :: [Char] -> Int > > safehash cs | length cs > 4 = error "safehash failed." > > | otherwise = > > sum [ (ord c)*(256^i) | (c,i) <- zip cs [0..3] ] > > > > -- a trie datatype > > data Trie a = Trie [a] (IM.IntMap (Trie a)) > > > > -- the empty trie > > emptyTrie = Trie [] (IM.empty) > > > > -- insert value into the trie > > insertTrie :: [String] -> a -> Trie a -> Trie a > > insertTrie [] i (Trie is maps) = Trie (i:is) maps > > insertTrie (word:words) i (Trie is maps) = > > let key = safehash word > > in case IM.lookup key maps of > > { Just trie -> let trie' = insertTrie words i trie > > maps' = IM.update (\x -> Just trie') key maps > > in Trie is maps' > > ; Nothing -> let trie = emptyTrie > > trie' = insertTrie words i trie > > maps' = IM.insert key trie' maps > > in Trie is maps' > > } > > > > -- lookup value from the trie > > lookupTrie :: [String] -> Trie a -> Maybe a > > lookupTrie [] (Trie vs _) = > > case vs of > > [] -> Nothing > > (x:_) -> Just x > > lookupTrie (word:words) (Trie is maps) = > > let key = safehash word > > in case IM.lookup key maps of > > Just trie -> lookupTrie words trie > > Nothing -> Nothing > > > > -- update the trie with the given value. > > updateTrie :: [String] -> a -> Trie a -> Trie a > > -- we only update the first value and leave the rest unchanged. > > updateTrie [] y (Trie (x:xs) maps) = Trie (y:xs) maps > > updateTrie (word:words) v (Trie is maps) = > > let key = safehash word > > in case IM.lookup key maps of > > Just trie -> let trie' = updateTrie words v trie > > maps' = IM.update (\x -> Just trie') key maps > > in Trie is maps' > > Nothing -> Trie is maps > > > > == BENCH MARK == > > > > I have a main function which builds a dictionary from a text file. > > Each line of the file is a key-value pair separated by a space. > > > > e.g. > > > > key1 1 > > key2 2 > > ... > > > > main :: IO () > > main = do { content <- readFile "in.txt" > > ; let -- change this following type annotation > > -- to change different type of the dictionary > > -- dict :: DM.Map S.ByteString Int > > -- dict :: IM.IntMap Int > > dict :: Trie Int > > dict = fromList (map parse_a_line (lines content)) > > ; case Main.lookup "key256" dict of > > { Just v -> putStrLn (show v) > > ; Nothing -> putStrLn "Not found" > > } > > -- read a line here so that we can pause the program > > -- and look at the memory usage. > > ; v <- readLn > > ; putStrLn v > > } > > where parse_a_line :: String -> (Key,Int) > > parse_a_line line = case words line of > > [key,val] -> (key,read val) > > _ -> error " parse error. " > > > > I tested all three implementations by building a dictionary of size > > 1000000. > > The result shows that the Map and the Trie approaches handle > collision > > well, but > > the IntMap approach does not. > > > > Here is a comparison of memory usage > > > > Map : 345 MB > > IntMap : 146 MB > > Trie : 282 MB > > Python : 94 MB > > > > Here is a comparison of execution time (on an intel dual core 2.0G) > > > > Map: 26 sec > > IntMap: 9 sec > > Trie: 12 sec > > Python: 2.24 sec > > > > The above number shows that my implementations of python style > dictionary > > are space/time in-efficient as compared to python. > > > > Can some one point out what's wrong with my implementations? > > > > I've attached my code in the tgz file. > > > > Cheers, > > Kenny > > > _______________________________________________ > > Haskell-Cafe mailing list > > [2]Haskell-Cafe@haskell.org > > [3]http://www.haskell.org/mailman/listinfo/haskell-cafe > > References > > Visible links > 1. mailto:dons@galois.com > 2. mailto:Haskell-Cafe@haskell.org > 3. http://www.haskell.org/mailman/listinfo/haskell-cafe From cppljevans at suddenlink.net Tue Nov 18 13:31:59 2008 From: cppljevans at suddenlink.net (Larry Evans) Date: Tue Nov 18 12:20:44 2008 Subject: [Haskell-cafe] Re: [off-topic] OOPer? In-Reply-To: References: <177953502.20081117004901@gmail.com> <1226947701.25951.10.camel@jcchost> <1f3dc80d0811171100h7394e3a2p1740cc17846c7195@mail.gmail.com> Message-ID: On 11/17/08 18:24, Daniel Yokomizo wrote: > On Mon, Nov 17, 2008 at 9:49 PM, Maur??cio > wrote: > > > (...) I don't recall where I found the following example, but > copied > > > it locally as compelling evidence that the functional solution > can be > > much clearer and shorter than the same solution modeled with > objects > > and inheritance. [snip] > > > -- Arithmetic expression forms data Expr = Num Int | Add Expr Expr > > > > -- Evaluate expressions > > eval :: Expr -> Int > > (...) > > > > public abstract class Expr { > > public abstract int eval (); > > public abstract void modn(int v); [snip] > when the first standard was set, and I can tell you for sure that, even > at that time, no one who knows at least the basics of C++ would ever > write that problem like this. Mauri, I'm not sure what you mean. Do you mean: 1) No C++er would ever "structure" the problem like: -- Arithmetic expression forms data Expr = Num Int | Add Expr Expr -- Evaluate expressions eval :: Expr -> Int eval (Num i) = i eval (Add l r ) = eval l + eval r If so, then I'm unsure what you could mean since the closest counterpart to: date Expr = Num Int | Add Expr Expr in c++ is an abstract Expr class with derived classes, Int and Add, just as shown in Greg's Java counterpart to the haskell Expr. 2) No C++er would every solve the problem with a heirarchy of Expr classes with virtual functions. If so, then I'm really confused because that's exactly the way I would do it *except* if I wanted to avoid the overhead of virtual function dispatch. In this case, I would use template metaprogramming (WARNING: not for c++ template metaprogramming novices): http://www.boost.org/doc/libs/1_37_0/doc/html/proto/users_guide.html#boost_proto.users_guide.intermediate_form.expression_introspection.defining_dsel_grammars In the proto metaprogramming, AFAICT, the 1st element of the proto::expr template, the tag, corresponds to Expr constructor's, Num and Add, of Greg's haskell example code. The | separating the Expr constructor variants corresponds to the proto::or_ template. So, if template metaprogramming were used, then there are some very good c++ programmer which would structure their c++ code like the haskell code (although, as seen by the #boost_proto.users_guide.intermediate_form.expression_introspection.defining_dsel_grammars reference, it's "a bit obscured" by all the "scaffolding" needed to make it work). Another reference which *may* reflect the haskell structure is: http://research.microsoft.com/~akenn/generics/gadtoop.pdf I must admit I don't really understand it, but it seems to have some similarities to haskell's structure. The author even uses haskell code to compare with his corresponding extension to c#. In particular, page 9 contains an example use of his proposed switch statement extension which looks very similar to the way haskell would pattern match on an expression to dispatch to the appropriate case. [snip] From dave at zednenem.com Tue Nov 18 12:37:14 2008 From: dave at zednenem.com (David Menendez) Date: Tue Nov 18 12:34:18 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> Message-ID: <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> 2008/11/18 kenny lu : > Here is a comparison of memory usage > > Map : 345 MB > IntMap : 146 MB > Trie : 282 MB > Python : 94 MB > > Here is a comparison of execution time (on an intel dual core 2.0G) > > Map: 26 sec > IntMap: 9 sec > Trie: 12 sec > Python: 2.24 sec > > > The above number shows that my implementations of python style dictionary > are space/time in-efficient as compared to python. > > Can some one point out what's wrong with my implementations? This isn't really a fair comparison. Map, IntMap, and Trie are persistent data structures, and Python dictionaries are ephemeral. (That is, when you "add" a key to a Map, you actually create a new one that shares structure with the old one, and both can be used in subsequent code. In Python, you would have to copy the dictionary.) -- Dave Menendez From phercek at gmail.com Tue Nov 18 13:05:05 2008 From: phercek at gmail.com (Peter Hercek) Date: Tue Nov 18 12:59:27 2008 Subject: [Haskell-cafe] Re: Type question in instance of a class In-Reply-To: <49a77b7a0811161620h59501171of1fdc37d2d3f847f@mail.gmail.com> References: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> <1115545264.20081117010308@gmail.com> <7ca3f0160811161609t5575ee0fh6f0bfcd574467cef@mail.gmail.com> <49a77b7a0811161620h59501171of1fdc37d2d3f847f@mail.gmail.com> Message-ID: David Menendez wrote: > On Sun, Nov 16, 2008 at 7:09 PM, Luke Palmer wrote: >> On Sun, Nov 16, 2008 at 5:06 PM, Peter Hercek wrote: >>> ... and the only value the function can return is bottom. >>> Is there any type system which would have more than >>> one value which inhabits all types? >> Well something like lazy C# might; i.e. every value has a _|_ >> (nontermination) and null (termination but undefined). > > For that matter, Control.Exception allows you to distinguish > exceptional values from each other. > OK, thanks for responses. I'm not sure I understand it well so I try to summarize: Control.Exception is an extension, also it probably cannot catch "error :: String -> a" since the report says so: http://www.haskell.org/onlinereport/exps.html#sect3.1 So Haskell'98 has only one value of all types (the bottom). But Haskell with Control.Exception extension has more values of all types since they can be thrown and later caught and investigated at that place. Maybe the last sentence of section 2.1 (_|_ Bottom) of "Haskell/Denotational semantics" should be clarified better. http://en.wikibooks.org/wiki/Haskell/Denotational_semantics#.E2.8A.A5_Bottom So when trying to use Curry-Howard isomorphism for something in Haskell, one sould be pretty carefull what features of are being used. Peter. From jgmorris at cecs.pdx.edu Tue Nov 18 13:08:42 2008 From: jgmorris at cecs.pdx.edu (J. Garrett Morris) Date: Tue Nov 18 13:02:49 2008 Subject: [Haskell-cafe] Re: Type question in instance of a class In-Reply-To: <4cf038ee0811180138m19ec6539ha645c02948502dd5@mail.gmail.com> References: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> <10610220603.20081117215503@gmail.com> <4cf038ee0811180138m19ec6539ha645c02948502dd5@mail.gmail.com> Message-ID: <6cf91caa0811181008o2a7b33a8h8ab3fdab3bc311c6@mail.gmail.com> On Tue, Nov 18, 2008 at 1:38 AM, Reiner Pope wrote: > ATs are "Associated Types", aka Type Families. They can be found in > the GHC 6.10 manual here: > http://haskell.org/ghc/docs/6.10.1/html/users_guide/type-families.html > > As a starting point, you might want to try something like: > > class Complex c where > type RealType c > realPart :: c -> RealType c > imagPart :: c -> RealType c I imagine that the generalized newtype deriving might be trickier to get working for this formulation. /g -- I am in here From jonathanccast at fastmail.fm Tue Nov 18 13:11:05 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Tue Nov 18 13:05:21 2008 Subject: [Haskell-cafe] Re: Type question in instance of a class In-Reply-To: References: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> <1115545264.20081117010308@gmail.com> <7ca3f0160811161609t5575ee0fh6f0bfcd574467cef@mail.gmail.com> <49a77b7a0811161620h59501171of1fdc37d2d3f847f@mail.gmail.com> Message-ID: <1227031865.31777.27.camel@jcchost> On Tue, 2008-11-18 at 19:05 +0100, Peter Hercek wrote: > David Menendez wrote: > > On Sun, Nov 16, 2008 at 7:09 PM, Luke Palmer wrote: > >> On Sun, Nov 16, 2008 at 5:06 PM, Peter Hercek wrote: > >>> ... and the only value the function can return is bottom. > >>> Is there any type system which would have more than > >>> one value which inhabits all types? > >> Well something like lazy C# might; i.e. every value has a _|_ > >> (nontermination) and null (termination but undefined). > > > > For that matter, Control.Exception allows you to distinguish > > exceptional values from each other. > > > > OK, thanks for responses. I'm not sure I understand it well > so I try to summarize: > > Control.Exception is an extension, also it probably cannot > catch "error :: String -> a" since the report says so: > http://www.haskell.org/onlinereport/exps.html#sect3.1 I think `cannot be caught by the user' is intended to be descriptive here; or, alternately, this is one place where GHC deviates from the spec. catch (error foo) h will certainly sometimes behave as h (UserError foo). Non-deterministically. jcc From lrpalmer at gmail.com Tue Nov 18 15:46:01 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Nov 18 15:40:10 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> Message-ID: <7ca3f0160811181246p63ce13adneb920f4ffde06f8c@mail.gmail.com> On Tue, Nov 18, 2008 at 10:37 AM, David Menendez wrote: > This isn't really a fair comparison. Map, IntMap, and Trie are > persistent data structures, and Python dictionaries are ephemeral. > (That is, when you "add" a key to a Map, you actually create a new one > that shares structure with the old one, and both can be used in > subsequent code. In Python, you would have to copy the dictionary.) But when these persistent data structures are used in a single-threaded way, why should we not hope for the performance to be comparable? It may not be easy, but just saying "they are persistent" is not really an excuse. Luke From dons at galois.com Tue Nov 18 15:52:38 2008 From: dons at galois.com (Don Stewart) Date: Tue Nov 18 15:46:45 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> Message-ID: <20081118205238.GD2422@scytale.galois.com> dave: > 2008/11/18 kenny lu : > > Here is a comparison of memory usage > > > > Map : 345 MB > > IntMap : 146 MB > > Trie : 282 MB > > Python : 94 MB > > > > Here is a comparison of execution time (on an intel dual core 2.0G) > > > > Map: 26 sec > > IntMap: 9 sec > > Trie: 12 sec > > Python: 2.24 sec > > > > > > The above number shows that my implementations of python style dictionary > > are space/time in-efficient as compared to python. > > > > Can some one point out what's wrong with my implementations? > > This isn't really a fair comparison. Map, IntMap, and Trie are > persistent data structures, and Python dictionaries are ephemeral. > (That is, when you "add" a key to a Map, you actually create a new one > that shares structure with the old one, and both can be used in > subsequent code. In Python, you would have to copy the dictionary.) > Strings, not ByteStrings. that's the difference. -- Don From duncan.coutts at worc.ox.ac.uk Tue Nov 18 16:16:02 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Nov 18 16:09:08 2008 Subject: [Haskell-cafe] Deploying a Binary Haskell Package In-Reply-To: References: Message-ID: <1227042962.21705.28.camel@dell.linuxdev.us.dell.com> On Tue, 2008-11-18 at 10:20 -0500, John Van Enk wrote: > This question isn't directly related to Haskell, but I figure some one > might know here. > > I want to deploy an application. I could either: > 1) Tell people how to download GHC, have them check out the > repository, have them install all the needed hackage packages, ... > or > 2) Give them a setup.msi/exe > > I'm curious if any one has done this with a Haskell package. It seems > that it's something that might make sense being integrated into Cabal > (runhaskell Setup msi). I think the right approach here is as a separate tool, like we have tools for generating native packages for rpm, deb and other distributions. Of course it only makes sense for applications, not libraries. > Either way, has some one deployed a Haskell binary as a MSI package? Not MSI[1] but .exe yes. Here's an example: http://haskell.org/~duncan/gtk2hs/LSystemSetup.exe It is an installer (made with the free InnoSetup builder) for a simple graphical application that uses HOpenGL, Gtk2Hs and therefore Gtk+. It installs the application .exe the Gtk+ dll files and a data file for the GUI. Duncan [1] On a job many years ago I had to make an MSI installer and now hate them with a passion :-) From duncan.coutts at worc.ox.ac.uk Tue Nov 18 16:24:58 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Nov 18 16:18:02 2008 Subject: [Haskell-cafe] GHC 6.10.1 and cabal[-install] In-Reply-To: <200811181423.12306.g9ks157k@acme.softbase.org> References: <200811181101.14630.g9ks157k@acme.softbase.org> <200811181423.12306.g9ks157k@acme.softbase.org> Message-ID: <1227043498.21705.36.camel@dell.linuxdev.us.dell.com> On Tue, 2008-11-18 at 14:23 +0100, Wolfgang Jeltsch wrote: > Am Dienstag, 18. November 2008 11:01 schrieb Wolfgang Jeltsch: > > Hello, > > > > I installed GHC 6.10.1 today and expected it to contain the cabal command > > line utility. Unfortunately, this was not the case. Where can I download > > it? > > Meanwhile, I found out that the package cabal-install includes the cabal > command. On the other hand I thought that there was a now deprecated command > line tool named cabal-install. I find this a bit confusing. The Cabal package provides the library. The cabal-install package provides the 'cabal' command line tool. The deprecated package you're thinking of is cabal-get or cabal-setup. > > How do I install and configure it so that it is integrated best with > > GHC 6.10.1? For example, should cabal use some directory in the GHC tree > > to place compiled packages in? The defaults for user or global should be fine. There is no need to put additional packages into the ghc install tree, indeed I would recommend against doing that. > Cabal wants to place package info in $HOME/.cabal. However, I want to install > packages globally with sudo. So I want to have a global package cache. Is > there a common directory to be used for that or is cabal[-install] only for > per-user installations? It can do per-user or global. Per-user is the default. If you want to do the build as user and just the install as root then you can use the --global --root-cmd=sudo options. If you want to use this every time then you can set that in the ~/.cabal/config file. > Well, there is the --global option but it is apparently only for registering > packages globally. Does it change the destination directory for the > installed packages too? Yes. > If yes, to what directory? /usr/local > Is the default --global or --user? --user > Sorry, but I cannot find the answers to this in the docs and I > don?t want to mess up my file system. The cabal user guide lists the default install directories for global and user installs. The default ~/.cabal/config file is slightly self-documenting in that it lists the available options and their defaults: [..snip..] -- user-install: True [..snip..] install-dirs user -- prefix: /home/duncan/.cabal [..snip..] install-dirs global -- prefix: /usr/local [..snip..] From duncan.coutts at worc.ox.ac.uk Tue Nov 18 16:30:05 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Nov 18 16:23:08 2008 Subject: [Haskell-cafe] Cabal and more than one version In-Reply-To: <42784f260811180148v7c48ed46p18132f44a377f8bf@mail.gmail.com> References: <42784f260811180148v7c48ed46p18132f44a377f8bf@mail.gmail.com> Message-ID: <1227043805.21705.42.camel@dell.linuxdev.us.dell.com> On Tue, 2008-11-18 at 01:48 -0800, Jason Dusek wrote: > I'd like to be able to do something like: > > if (template-haskell < 2.3) > cpp-options: -D TH_THE_YOUNGER > else > cpp-options: -D TH_THE_ELDER > > I guess this kind of thing is not possible at present? It is possible, in two different ways. The easiest way is that if you're using Cabal-1.6 then it provides cpp macros to test the version number of packages you're using. #if MIN_VERSION_template_haskell(2,3,0) ... #elseif ... #endif The alternative that works back to Cabal-1.2 is to use: flag newer-th ... if flag(newer-th) build-depends: template-haskell >= 2.3 cpp-options: -D TH_THE_ELDER else build-depends: template-haskell < 2.3 cpp-options: -D TH_THE_YOUNGER See also ticket http://hackage.haskell.org/trac/hackage/ticket/209 for a proposal to add syntactic sugar similar to the syntax you first suggested. Duncan From qdunkan at gmail.com Tue Nov 18 16:34:41 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Tue Nov 18 16:34:12 2008 Subject: clojure's data structures (was: Re: [Haskell-cafe] implementing python-style dictionary in Haskell) Message-ID: <2518b95d0811181334j38dcc4b2j710d4c4f34b674e6@mail.gmail.com> This actually brings up something I was wondering about lately. I recently stumbled across a language called clojure, which is a lisp-like that runs on the JVM. The interesting thing is that mutations go through a transactional mutable reference system, and the other datastructures are all immutable. The author implements an immutable hash map with a trie on each 5 bits of the hash, so each node potentially has 32 children. This means that lookups are effectively O(1) and alterations have to copy a maximum of 7 chunks of 32 pointers. Extendable "vectors" are implemented similarly. The hash tables sound basically like an IntMap on the hash code, except as far as I know, IntMap's patricia tree splits up the bit space adaptively instead of being hardcoded on 5 bit segments. I'm not sure what the performance difference would be. I haven't run any tests, but the clojure author claims his vector and hash map are quite fast. I suppose the extendable vector corresponds to the current crop of ByteString-like variants, so we sort of already have that, though in a kind of chaotic and inchoate way. I'm also curious about how far the generalized trie SoC project got... it should be more accessible now that we have a mainline release with ATs, right? From agocorona at gmail.com Tue Nov 18 16:42:49 2008 From: agocorona at gmail.com (Alberto G. Corona ) Date: Tue Nov 18 16:36:57 2008 Subject: Fwd: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> <20081118205238.GD2422@scytale.galois.com> Message-ID: sorry, Dons, ---------- Forwarded message ---------- From: Alberto G. Corona Date: 2008/11/18 Subject: Re: [Haskell-cafe] implementing python-style dictionary in Haskell To: Don Stewart By the way byteStrings are wonderful, but, it isn?t true that byteStrings are not so fast for managing short strings, for example keys ? 2008/11/18 Don Stewart dave: > > 2008/11/18 kenny lu : > > > Here is a comparison of memory usage > > > > > > Map : 345 MB > > > IntMap : 146 MB > > > Trie : 282 MB > > > Python : 94 MB > > > > > > Here is a comparison of execution time (on an intel dual core 2.0G) > > > > > > Map: 26 sec > > > IntMap: 9 sec > > > Trie: 12 sec > > > Python: 2.24 sec > > > > > > > > > The above number shows that my implementations of python style > dictionary > > > are space/time in-efficient as compared to python. > > > > > > Can some one point out what's wrong with my implementations? > > > > This isn't really a fair comparison. Map, IntMap, and Trie are > > persistent data structures, and Python dictionaries are ephemeral. > > (That is, when you "add" a key to a Map, you actually create a new one > > that shares structure with the old one, and both can be used in > > subsequent code. In Python, you would have to copy the dictionary.) > > > > Strings, not ByteStrings. that's the difference. > > -- Don > _______________________________________________ > 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/20081118/bebc6a92/attachment.htm From andrewcoppin at btinternet.com Tue Nov 18 16:51:06 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Tue Nov 18 16:45:15 2008 Subject: [Haskell-cafe] GHC 6.10.1 and cabal[-install] In-Reply-To: <1227043498.21705.36.camel@dell.linuxdev.us.dell.com> References: <200811181101.14630.g9ks157k@acme.softbase.org> <200811181423.12306.g9ks157k@acme.softbase.org> <1227043498.21705.36.camel@dell.linuxdev.us.dell.com> Message-ID: <492338CA.6090004@btinternet.com> Duncan Coutts wrote: > The Cabal package provides the library. The cabal-install package > provides the 'cabal' command line tool. > > The deprecated package you're thinking of is cabal-get or cabal-setup. > Will Hackage one day provide a way to discover that one package has been superceeded by another? Currently you can see when a newer version of the exact same package exists, but (for example) take a took at how many gazillion database packages there are up there. Which ones are active? Which ones are obsolete? How can I tell?? From dave at zednenem.com Tue Nov 18 16:54:18 2008 From: dave at zednenem.com (David Menendez) Date: Tue Nov 18 16:48:26 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <20081118205238.GD2422@scytale.galois.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> <20081118205238.GD2422@scytale.galois.com> Message-ID: <49a77b7a0811181354l6b469250k7f9eff07818f9b39@mail.gmail.com> On Tue, Nov 18, 2008 at 3:52 PM, Don Stewart wrote: > dave: >> 2008/11/18 kenny lu : >> > The above number shows that my implementations of python style dictionary >> > are space/time in-efficient as compared to python. >> > >> > Can some one point out what's wrong with my implementations? >> >> This isn't really a fair comparison. Map, IntMap, and Trie are >> persistent data structures, and Python dictionaries are ephemeral. >> (That is, when you "add" a key to a Map, you actually create a new one >> that shares structure with the old one, and both can be used in >> subsequent code. In Python, you would have to copy the dictionary.) >> > > Strings, not ByteStrings. that's the difference. Is that in response to what I wrote, or to the original question? Speaking of ByteStrings and tries, has anyone implemented a Patricia Trie for ByteStrings? I started putting one together a while back, but I got distracted and never finished it. -- Dave Menendez From dagit at codersbase.com Tue Nov 18 16:56:32 2008 From: dagit at codersbase.com (Jason Dagit) Date: Tue Nov 18 16:50:40 2008 Subject: [Haskell-cafe] GHC 6.10.1 and cabal[-install] In-Reply-To: <492338CA.6090004@btinternet.com> References: <200811181101.14630.g9ks157k@acme.softbase.org> <200811181423.12306.g9ks157k@acme.softbase.org> <1227043498.21705.36.camel@dell.linuxdev.us.dell.com> <492338CA.6090004@btinternet.com> Message-ID: On Tue, Nov 18, 2008 at 1:51 PM, Andrew Coppin wrote: > Duncan Coutts wrote: > >> The Cabal package provides the library. The cabal-install package >> provides the 'cabal' command line tool. >> >> The deprecated package you're thinking of is cabal-get or cabal-setup. >> >> > > Will Hackage one day provide a way to discover that one package has been > superceeded by another? > > Currently you can see when a newer version of the exact same package > exists, but (for example) take a took at how many gazillion database > packages there are up there. Which ones are active? Which ones are obsolete? > How can I tell?? This has come up before. As you can see here: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/46764 I think we just need someone (how about you!?) to start working on it. Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081118/44baaad1/attachment.htm From andrewcoppin at btinternet.com Tue Nov 18 17:00:39 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Tue Nov 18 16:54:48 2008 Subject: [Haskell-cafe] GHC 6.10.1 and cabal[-install] In-Reply-To: References: <200811181101.14630.g9ks157k@acme.softbase.org> <200811181423.12306.g9ks157k@acme.softbase.org> <1227043498.21705.36.camel@dell.linuxdev.us.dell.com> <492338CA.6090004@btinternet.com> Message-ID: <49233B07.7000709@btinternet.com> Jason Dagit wrote: > > > On Tue, Nov 18, 2008 at 1:51 PM, Andrew Coppin > > wrote: > > Duncan Coutts wrote: > > The Cabal package provides the library. The cabal-install package > provides the 'cabal' command line tool. > > The deprecated package you're thinking of is cabal-get or > cabal-setup. > > > > Will Hackage one day provide a way to discover that one package > has been superceeded by another? > > Currently you can see when a newer version of the exact same > package exists, but (for example) take a took at how many > gazillion database packages there are up there. Which ones are > active? Which ones are obsolete? How can I tell?? > > > This has come up before. As you can see here: > http://thread.gmane.org/gmane.comp.lang.haskell.cafe/46764 > > I think we just need someone (how about you!?) to start working on it. What do I need to do? Just obtain the Hackage source code and submit a Darcs patch or something? Or is it harder than that? From dagit at codersbase.com Tue Nov 18 17:03:26 2008 From: dagit at codersbase.com (Jason Dagit) Date: Tue Nov 18 16:57:34 2008 Subject: [Haskell-cafe] GHC 6.10.1 and cabal[-install] In-Reply-To: <49233B07.7000709@btinternet.com> References: <200811181101.14630.g9ks157k@acme.softbase.org> <200811181423.12306.g9ks157k@acme.softbase.org> <1227043498.21705.36.camel@dell.linuxdev.us.dell.com> <492338CA.6090004@btinternet.com> <49233B07.7000709@btinternet.com> Message-ID: On Tue, Nov 18, 2008 at 2:00 PM, Andrew Coppin wrote: > Jason Dagit wrote: > > >> >> On Tue, Nov 18, 2008 at 1:51 PM, Andrew Coppin < >> andrewcoppin@btinternet.com > wrote: >> >> Duncan Coutts wrote: >> >> The Cabal package provides the library. The cabal-install package >> provides the 'cabal' command line tool. >> >> The deprecated package you're thinking of is cabal-get or >> cabal-setup. >> >> >> Will Hackage one day provide a way to discover that one package >> has been superceeded by another? >> >> Currently you can see when a newer version of the exact same >> package exists, but (for example) take a took at how many >> gazillion database packages there are up there. Which ones are >> active? Which ones are obsolete? How can I tell?? >> >> >> This has come up before. As you can see here: >> http://thread.gmane.org/gmane.comp.lang.haskell.cafe/46764 >> >> I think we just need someone (how about you!?) to start working on it. >> > > What do I need to do? Just obtain the Hackage source code and submit a > Darcs patch or something? Or is it harder than that? A darcs patch should work. If you look in the thread I linked to you'll see this message by Thomas M. DuBuisson: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/46764 Where he gives the location of secret hideout for the hackage happs server and how to contribute. Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081118/ce344da5/attachment.htm From dagit at codersbase.com Tue Nov 18 17:04:16 2008 From: dagit at codersbase.com (Jason Dagit) Date: Tue Nov 18 16:58:24 2008 Subject: [Haskell-cafe] GHC 6.10.1 and cabal[-install] In-Reply-To: References: <200811181101.14630.g9ks157k@acme.softbase.org> <200811181423.12306.g9ks157k@acme.softbase.org> <1227043498.21705.36.camel@dell.linuxdev.us.dell.com> <492338CA.6090004@btinternet.com> <49233B07.7000709@btinternet.com> Message-ID: On Tue, Nov 18, 2008 at 2:03 PM, Jason Dagit wrote: > > > On Tue, Nov 18, 2008 at 2:00 PM, Andrew Coppin < > andrewcoppin@btinternet.com> wrote: > >> Jason Dagit wrote: >> >> >>> >>> On Tue, Nov 18, 2008 at 1:51 PM, Andrew Coppin < >>> andrewcoppin@btinternet.com > wrote: >>> >>> Duncan Coutts wrote: >>> >>> The Cabal package provides the library. The cabal-install package >>> provides the 'cabal' command line tool. >>> >>> The deprecated package you're thinking of is cabal-get or >>> cabal-setup. >>> >>> >>> Will Hackage one day provide a way to discover that one package >>> has been superceeded by another? >>> >>> Currently you can see when a newer version of the exact same >>> package exists, but (for example) take a took at how many >>> gazillion database packages there are up there. Which ones are >>> active? Which ones are obsolete? How can I tell?? >>> >>> >>> This has come up before. As you can see here: >>> http://thread.gmane.org/gmane.comp.lang.haskell.cafe/46764 >>> >>> I think we just need someone (how about you!?) to start working on it. >>> >> >> What do I need to do? Just obtain the Hackage source code and submit a >> Darcs patch or something? Or is it harder than that? > > > A darcs patch should work. If you look in the thread I linked to you'll > see this message by Thomas M. DuBuisson: > By copy and paste, my apologies: http://article.gmane.org/gmane.comp.lang.haskell.cafe/46773 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081118/3827640f/attachment.htm From vigalchin at gmail.com Tue Nov 18 17:45:41 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Tue Nov 18 17:39:48 2008 Subject: [Haskell-cafe] Haskell library support In-Reply-To: References: <5ae4f2ba0811141336r26b4e39h79b7076bbbcdee5e@mail.gmail.com> Message-ID: <5ae4f2ba0811181445p2bff819bufcf1ace30248b1e6@mail.gmail.com> Hi Jeff, Is http://haskell.org/haskellwiki/Wanted_libraries kept up to date? I wouldn't want to reinvent a wheel ;^) Vasili On Mon, Nov 17, 2008 at 7:04 PM, Jeff Zaroyko wrote: > 2008/11/15 Galchin, Vasili : > > Hello, > > > > I am looking for something to work on. Where are there perceived > holes > > in the Haskell library support? > > > > Regards, Vasili > > Hello Vasili > > Maybe the haskell.org wiki would be a good place for people to record > their suggestions? http://haskell.org/haskellwiki/Wanted_libraries > looks like a suitable place. > > Regards, Jeff > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081118/aa0e11a1/attachment.htm From min at cse.unsw.edu.au Tue Nov 18 17:55:20 2008 From: min at cse.unsw.edu.au (Kyongho Min) Date: Tue Nov 18 17:49:30 2008 Subject: [Haskell-cafe] How to make interface IO() to IO a in a command-driven tool Message-ID: <492347D8.4010407@cse.unsw.edu.au> Dear Haskell users, I am working on a command-driven tool (::IO ()). If the system invokes itself again, and the system's returned data type would be 'IO a', say (IO Exp) (Expression). tool:: a -> IO() The nested tool invocation returns (IO Exp) to the previous tool. I am using dynamic error exception handling like (throwDyn exp). If I use 'forkIO', then it works for this situation (e.g. IO Exp) but it is not working for 'quit' command (quit the tool:: thread blocked indefinitely) - quit the subtool and return to the previous tool. Any suggestion would be helpful? tool = {tool1, tool2, tool3, ...} tool1:: (IO ()) invoked tool2:: (IO a) may invoked tool3:: (IO a) tool2 is working basically on IO() and if I got the Exp (proved), then return it to the previous tool (say tool1). Thanks in advance, min From ryani.spam at gmail.com Tue Nov 18 18:44:04 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Nov 18 18:38:12 2008 Subject: [Haskell-cafe] Pattern matching on numbers? Message-ID: <2f9b2d30811181544h45cc5cd0vdeed0047af8d7356@mail.gmail.com> How does this work? > fac n = case n of > 0 -> 1 > _ -> n * fac (n-1) ghci> :t fac fac :: (Num t) => t -> t The first line of "fac" pattern matches on 0. So how does this work over any value of the Num typeclass? I know that the "1" on the rhs of fac are replaced with (fromInteger 1), but what about numeric literals in patterns? Does it turn into a call to (==)? Should whatever technique is used be extended to other typeclasses too? -- ryan From lemming at henning-thielemann.de Tue Nov 18 18:56:27 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Nov 18 18:50:37 2008 Subject: [Haskell-cafe] Pattern matching on numbers? In-Reply-To: <2f9b2d30811181544h45cc5cd0vdeed0047af8d7356@mail.gmail.com> References: <2f9b2d30811181544h45cc5cd0vdeed0047af8d7356@mail.gmail.com> Message-ID: On Tue, 18 Nov 2008, Ryan Ingram wrote: > How does this work? > >> fac n = case n of >> 0 -> 1 >> _ -> n * fac (n-1) > > ghci> :t fac > fac :: (Num t) => t -> t > > The first line of "fac" pattern matches on 0. So how does this work > over any value of the Num typeclass? I know that the "1" on the rhs > of fac are replaced with (fromInteger 1), but what about numeric > literals in patterns? Does it turn into a call to (==)? As far as I know, yes. It is even possible to trap into an error on pattern matching this way if fromInteger generates an 'undefined'. > Should whatever technique is used be extended to other typeclasses too? It is unusual to do pattern matching on fractions, you mostly need it for recursion on natural numbers. Thus I think the cleanest solution would be to treat natural numbers like strict Peano numbers data PeanoStrict = Zero | Succ !PeanoStrict but with an efficient implementation using GMP integers, maybe using 'views', if they were part of Haskell language. Then you can implement: fac :: Integer -> Integer fac Zero = 1 fac n1@(Succ n) = n1 * fac n I would then give up pattern matching on any numeric type. From dave at zednenem.com Tue Nov 18 18:57:09 2008 From: dave at zednenem.com (David Menendez) Date: Tue Nov 18 18:51:17 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <7ca3f0160811181246p63ce13adneb920f4ffde06f8c@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> <7ca3f0160811181246p63ce13adneb920f4ffde06f8c@mail.gmail.com> Message-ID: <49a77b7a0811181557w5473992bm969a3a594f741dcd@mail.gmail.com> On Tue, Nov 18, 2008 at 3:46 PM, Luke Palmer wrote: > On Tue, Nov 18, 2008 at 10:37 AM, David Menendez wrote: >> This isn't really a fair comparison. Map, IntMap, and Trie are >> persistent data structures, and Python dictionaries are ephemeral. >> (That is, when you "add" a key to a Map, you actually create a new one >> that shares structure with the old one, and both can be used in >> subsequent code. In Python, you would have to copy the dictionary.) > > But when these persistent data structures are used in a > single-threaded way, why should we not hope for the performance to be > comparable? > > It may not be easy, but just saying "they are persistent" is not > really an excuse. I guess that depends on what you mean by "comparable". Chris Okasaki demonstrated that, for some data structures, a persistent implementation could be made with the same asymptotic bounds as an ephemeral implementation, but I would still expect the persistent version to be worse by a constant factor when used ephemerally. Ephemeral data structures are naturally optimized for ephemeral use cases. (I would also expect the reverse to be true.) -- Dave Menendez From allbery at ece.cmu.edu Tue Nov 18 18:59:47 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Nov 18 18:53:58 2008 Subject: [Haskell-cafe] How to make interface IO() to IO a in a command-driven tool In-Reply-To: <492347D8.4010407@cse.unsw.edu.au> References: <492347D8.4010407@cse.unsw.edu.au> Message-ID: <8AD2F54F-C988-4509-9AC5-6F8211CEC9C7@ece.cmu.edu> On 2008 Nov 18, at 17:55, Kyongho Min wrote: > I am working on a command-driven tool (::IO ()). > If the system invokes itself again, and the system's returned > data type would be 'IO a', say (IO Exp) (Expression). > > tool:: a -> IO() > > The nested tool invocation returns (IO Exp) to the previous tool. > I am using dynamic error exception handling like (throwDyn exp). > > If I use 'forkIO', then it works for this situation (e.g. IO Exp) > but it is not working for 'quit' command (quit the tool:: thread > blocked indefinitely) - quit the subtool and return to the previous > tool. Consider using a special type of dynamic exception to mean "quit". -- 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 dave at zednenem.com Tue Nov 18 19:00:18 2008 From: dave at zednenem.com (David Menendez) Date: Tue Nov 18 18:54:25 2008 Subject: [Haskell-cafe] Pattern matching on numbers? In-Reply-To: References: <2f9b2d30811181544h45cc5cd0vdeed0047af8d7356@mail.gmail.com> Message-ID: <49a77b7a0811181600keeb9de2j126416e6d3ad1cb@mail.gmail.com> On Tue, Nov 18, 2008 at 6:56 PM, Henning Thielemann wrote: > > On Tue, 18 Nov 2008, Ryan Ingram wrote: > >> How does this work? >> >>> fac n = case n of >>> 0 -> 1 >>> _ -> n * fac (n-1) >> >> ghci> :t fac >> fac :: (Num t) => t -> t >> >> The first line of "fac" pattern matches on 0. So how does this work >> over any value of the Num typeclass? I know that the "1" on the rhs >> of fac are replaced with (fromInteger 1), but what about numeric >> literals in patterns? Does it turn into a call to (==)? > > As far as I know, yes. It is even possible to trap into an error on pattern > matching this way if fromInteger generates an 'undefined'. As I understand it, the use of (==) in numeric pattern matching is why Num requires Eq. -- Dave Menendez From jason.dusek at gmail.com Tue Nov 18 19:53:49 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Tue Nov 18 19:47:57 2008 Subject: [Haskell-cafe] Cabal and more than one version In-Reply-To: <1227043805.21705.42.camel@dell.linuxdev.us.dell.com> References: <42784f260811180148v7c48ed46p18132f44a377f8bf@mail.gmail.com> <1227043805.21705.42.camel@dell.linuxdev.us.dell.com> Message-ID: <42784f260811181653o7a8c1d35ydde860bf95f7b70a@mail.gmail.com> In the ticket, someone says: True though I suspect it looks a bit weird to the uninitiated. We know to read the conditional syntax as an implication constraint which can be applied in either direction but I suspect many people read it in a directed functional way. Does that mean you don't have to actually set 'splitBase' explicitly? -- _jsn From briqueabraque at yahoo.com Tue Nov 18 20:07:54 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Tue Nov 18 20:02:10 2008 Subject: [Haskell-cafe] FFI and returning structs Message-ID: Hi, I have not found examples of this in documentation or hackage packages: how can I deal with funcions returning not pointers to structs but structs thenselves? struct example {... example function_name (... My intuition said I could try a data declaration that is a properly done instance of Storable, and then use that. data Example = ... instance Storable Example where ... But it seems I was wrong. Do you have any tips on how to proceed? Thanks, Maur?cio From jeffzaroyko at gmail.com Tue Nov 18 20:56:57 2008 From: jeffzaroyko at gmail.com (Jeff Zaroyko) Date: Tue Nov 18 20:51:04 2008 Subject: [Haskell-cafe] Haskell library support In-Reply-To: <5ae4f2ba0811181445p2bff819bufcf1ace30248b1e6@mail.gmail.com> References: <5ae4f2ba0811141336r26b4e39h79b7076bbbcdee5e@mail.gmail.com> <5ae4f2ba0811181445p2bff819bufcf1ace30248b1e6@mail.gmail.com> Message-ID: On Wed, Nov 19, 2008 at 9:45 AM, Galchin, Vasili wrote: > Hi Jeff, > > Is http://haskell.org/haskellwiki/Wanted_libraries kept up to date? I > wouldn't want to reinvent a wheel ;^) > > Vasili > Hi Vasili, I was hoping that this thread could spur some interest from people to update it with their most recent wishes. I'm not sure about a lot of the things on there already, but I removed the request for .NET interop since Salsa is on hackage now and I added a wish for x86-64 support for Harpy. Beyond that, I don't really have a feel for what's missing since I can think of many programs that I'd like to write with what's available already. I've also just submitted the link [1] to the Haskell reddit, which will hopefully reach some people who aren't subscribed to this list. 1. http://www.reddit.com/r/haskell/comments/7e8wt/wanted_libraries_a_wishlist_for_haskell_libraries/ -Jeff From warrensomebody at gmail.com Tue Nov 18 21:23:29 2008 From: warrensomebody at gmail.com (Warren Harris) Date: Tue Nov 18 21:17:41 2008 Subject: [Haskell-cafe] streaming translation using monads Message-ID: <38C9CD80-7FFB-43EB-9970-258A5ACEB8A0@gmail.com> I am working on a query language translator, and although I feel that a monadic formulation would work well for this application, I've stumbled on a number of questions and difficulties that I thought the knowledgeable people here might be able to help me with. As a translator, there's a source language and a target language, and both of these are specified as a grammar of nested expressions. My first thought was to formulate the target language as an embedded language where each clause expression is represented as a monad operation, so that the bind operator can join the pieces together, e.g.: (clause1, clause2 ...) could be specified as an embedded language as: clause1 >>= \ v1 -> clause2 >>= \ v2 -> ... However, each of the clauses is actually an output routine to send the expression that it denotes to a remote server, and a parser for receiving the results. Since a clause is really a pair of operations, it doesn't seem possible to formulate a monad that will compose all the output routines together and compose all the input routines together in one shot. (Note that the variables in the above code (v1, v2) represent inputs to be received from the remote server -- all outputs are packaged into the clause expressions themselves and are effectively literals.) A naive formulation of a monad to implement the above as "output -> input v" might appear to work, but has the ill-effect of interleaving the output and input statements for each clause rather than composing something that can send the entire request, and then receive the entire result. This forces me to use "output * input v" as the type of each clause expression, but now it is not possible to write a monad with a bind operation that will compose pieces in terms of input variables. Instead I have had to resort to using a set of combinators that thread a continuation function through each clause and accumulate inputs as they are received: clause1 ==> (\ k v1 -> k (trans1 v1)) ++ clause2 ==> (\ k v2 -> k (trans2 v2)) ++ ... This threading is necessary in that I want to stream the translation back to the client requesting the translation rather than building up the (possibly large) results in memory. This formulation has proven to be quite cumbersome in practice, as the resulting continuation types reflect the depth-first traversal of the nested query expressions, and type errors can be quite unintuitive. (It is quite interesting though that each continuation/transformation function can receive not only receive the input from the immediately preceding clause, but from any of the preceding clauses, and also return more or fewer results. However getting anything wrong can be very problematic in that it can lead to either downstream *or* upstream errors depending on how the clauses are composed into an overall query expression.) An alternative to all this would be to use an algebraic datatype to specify the target language (with separate routines for the output and input operations), but that would appear to require another sum type to express the values to be received. I'd like to avoid that if possible since the projection of those values back into my program could lead to dynamic type errors, and also causes seemingly needless memory allocations. There must be another technique for this sort of streaming translation out there... I welcome any suggestions you might have! Warren Harris From allbery at ece.cmu.edu Tue Nov 18 21:53:03 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Nov 18 21:47:13 2008 Subject: [Haskell-cafe] streaming translation using monads In-Reply-To: <38C9CD80-7FFB-43EB-9970-258A5ACEB8A0@gmail.com> References: <38C9CD80-7FFB-43EB-9970-258A5ACEB8A0@gmail.com> Message-ID: <068EC4D2-91A5-4071-9719-1D7C9CA5CCB6@ece.cmu.edu> On 2008 Nov 18, at 21:23, Warren Harris wrote: > However, each of the clauses is actually an output routine to send > the expression that it denotes to a remote server, and a parser for > receiving the results. Since a clause is really a pair of > operations, it doesn't seem possible to formulate a monad that will > compose all the output routines together and compose all the input > routines together in one shot. (Note that the variables in the above > code (v1, v2) represent inputs to be received from the remote server > -- all outputs are packaged into the clause expressions themselves > and are effectively literals.) Have you considered using arrows instead? -- 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 ryani.spam at gmail.com Tue Nov 18 22:51:28 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Nov 18 22:45:35 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <7ca3f0160811181246p63ce13adneb920f4ffde06f8c@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> <7ca3f0160811181246p63ce13adneb920f4ffde06f8c@mail.gmail.com> Message-ID: <2f9b2d30811181951l5e3cd89ejf0ac46d39dfd1bf0@mail.gmail.com> On Tue, Nov 18, 2008 at 12:46 PM, Luke Palmer wrote: > But when these persistent data structures are used in a > single-threaded way, why should we not hope for the performance to be > comparable? If you can guarantee single-threaded use, then you can just use ST and implement the ephemeral structure, right? > It may not be easy, but just saying "they are persistent" is not > really an excuse. You can generally make a persistent data structure with the same asymptotic bounds as the ephemeral structure, but the constant hidden inside the O() will generally be worse. From ryani.spam at gmail.com Tue Nov 18 23:39:18 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Nov 18 23:33:24 2008 Subject: [Haskell-cafe] Monadic bind with associated types + PHOAS? Message-ID: <2f9b2d30811182039n5830b80fre5ae07456a97a0a5@mail.gmail.com> This is an idea that has been bouncing around in my head for a while, having to do with embedded languages. A few of the talks at CUFP this year mentioned using Haskell to embed a DSL that gets compiled into the output of the program; the hydraulic engine talk embedded the code for the real-time safety computation in the trucks, and one of the finance talks embedded a language for designing Excel spreadsheets. One thing that often comes up is a desire to do a pass on the resultant code to optimize it, but it's pretty difficult with the standard monadic formulation because of embedded functions. You can't do introspection on functions in Haskell; they aren't elements of Eq or Show. This has caused, for example, some implementations of FRP to switch to using arrows instead. However, I find the arrow syntax cumbersome and I feel it tends to obfuscate what is actually going on in the code. An earlier talk at ICFP mentioned using PHOAS instead of HOAS to encode expressions. In HOAS, a lambda expression in the target language is represented by a function in the source language: > data ExpE t where > ApE :: ExpE (a -> b) -> ExpE a -> ExpE b > LamE :: (ExpE a -> ExpE b) -> ExpE (a -> b) But without a way to inspect the function inside LamE, you can't get back to the "source code". You end up adding special constructors for "Primitive" or "Variable" to let you do something with the resultant structure, which leads to the expression language containing "unsafe" constructors which need to be hidden. PHOAS makes a small change to make many of these things possible without compromising safety: > data ExpP v t where > VarP :: v t -> ExpP v t > ApP :: ExpP v (a -> b) -> ExpP v a -> ExpP v b > LamP :: (v a -> ExpP v b) -> ExpP v (a -> b) > > newtype Exp t = Exp (forall v. ExpP v t) Now, by parametricity, if you are constructing an Exp t, the only useful thing you can do with the variable passed to LamP is give it to VarP. This means the code using it is basically the same as the HOAS code, except a couple of extra "VarP" constructors inserted, but you gain the ability to inspect inside the lambda and extract the code it generates! An couple of examples, from a PHOAS test I wrote up: 1) An evaluator > eval :: Exp t -> t > eval (Exp e) = evalP e > > newtype Prim a = Prim a > evalP :: ExpP Prim t -> t > evalP (VarP (Prim a)) = a > evalP (ApP e1 e2) = evalPrim e1 $ evalPrim e2 > evalP (LamP f) = evalPrim . f . VarP . Prim 2) using "show" to peek inside functions! ] -- implementation is an exercise for the reader ] -- you'll learn a lot! :) ] ] newtype Var a = Var String ] showExp :: ExpP Var a -> ShowS ghci> let test = Exp $ Lam $ \a -> Lam $ \b -> Var a ghci> :t test test :: Exp (t -> t1 -> t) ghci> print test \x y -> x It seems to me this exact transformation could be useful to express "variable binding" in embedded languages! > type family Primitive m a > type family BoundVar m a > class PMonad m where > preturn :: Primitive m a -> m a > pbind :: m a -> (BoundVar m a -> m b) -> m b Now, this strictly generalizes regular monads: > newtype Wrap m a = Wrap (m a) > unwrap (Wrap m) = m > type instance Primitive (Wrap m) a = a > type instance BoundVar (Wrap m) a = a > instance Monad m => PMonad (Wrap m) where > preturn x = WM (return x) > pbind m f = WM (unwrap m >>= unwrap . f) So, it seems like the do-notation should work on this type, although you lose pattern matching ([x] <- getArgs). And you can use PHOAS techniques to build up a structure that you can introspect and optimize. Does anyone think this is a direction worth pursuing? It seems to me like a point where the current syntax of Haskell could mesh well with the new type-system technology that we keep getting from GHC HQ. -- ryan From lrpalmer at gmail.com Tue Nov 18 23:47:39 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Nov 18 23:41:47 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <2f9b2d30811181951l5e3cd89ejf0ac46d39dfd1bf0@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> <7ca3f0160811181246p63ce13adneb920f4ffde06f8c@mail.gmail.com> <2f9b2d30811181951l5e3cd89ejf0ac46d39dfd1bf0@mail.gmail.com> Message-ID: <7ca3f0160811182047v31305cd4ie9ee7f6110c899d@mail.gmail.com> On Tue, Nov 18, 2008 at 8:51 PM, Ryan Ingram wrote: > On Tue, Nov 18, 2008 at 12:46 PM, Luke Palmer wrote: >> But when these persistent data structures are used in a >> single-threaded way, why should we not hope for the performance to be >> comparable? > > If you can guarantee single-threaded use, then you can just use ST and > implement the ephemeral structure, right? But that requires a special reimplementation. >> It may not be easy, but just saying "they are persistent" is not >> really an excuse. > > You can generally make a persistent data structure with the same > asymptotic bounds as the ephemeral structure, but the constant hidden > inside the O() will generally be worse. I say this as a goal. If we're in a performance competition, we can't say "well, it's okay that Haskell is slower because its data structures can be used persistently". Python's dictionaries can also, by inserting explicit copies. In this use case Python performs better, and we should strive to perform as well as it does. Persistence has no bearing on this, because the persistence is not used. I'm not saying it's always possible to perform just as well. But persistence *by itself* is not a valid argument for poor performance. Luke From oleg at okmij.org Wed Nov 19 00:21:39 2008 From: oleg at okmij.org (oleg@okmij.org) Date: Wed Nov 19 00:16:16 2008 Subject: [Haskell-cafe] Monadic bind with associated types + PHOAS? Message-ID: <20081119052139.7EC25AE54@Adric.metnet.fnmoc.navy.mil> Ryan Ingram wrote: > One thing that often comes up is a desire to do a pass on the > resultant code to optimize it, but it's pretty difficult with the > standard monadic formulation because of embedded functions. You can't > do introspection on functions in Haskell; they aren't elements of Eq > or Show. This has caused, for example, some implementations of FRP to > switch to using arrows instead. However, I find the arrow syntax > cumbersome and I feel it tends to obfuscate what is actually going on > in the code. > > An earlier talk at ICFP mentioned using PHOAS instead of HOAS to > encode expressions. In HOAS, a lambda expression in the target > language is represented by a function in the source language: If one uses a tagless final representation, one benefits from the conveniences of the higher-order abstract syntax and yet gains the ability to show terms, count the number of constructors and even partially evaluate them (i.e., optimize). For the example, please see http://okmij.org/ftp/tagless-final/Incope.hs (in particular, see Semantics2 for the partial evaluator that does not use GADT). We can easily add an interpreter that does a CPS transform, thus letting us embed a CBV object language in a Haskell without any use of monad or the change of syntax of the object language. We can easily extend the language to add state (as we have done in the OCaml part of the project). http://okmij.org/ftp/tagless-final/README.txt From dons at galois.com Wed Nov 19 03:12:44 2008 From: dons at galois.com (Don Stewart) Date: Wed Nov 19 03:06:52 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <49a77b7a0811181354l6b469250k7f9eff07818f9b39@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> <20081118205238.GD2422@scytale.galois.com> <49a77b7a0811181354l6b469250k7f9eff07818f9b39@mail.gmail.com> Message-ID: <20081119081244.GA5974@scytale.galois.com> dave: > On Tue, Nov 18, 2008 at 3:52 PM, Don Stewart wrote: > > dave: > >> 2008/11/18 kenny lu : > >> > The above number shows that my implementations of python style dictionary > >> > are space/time in-efficient as compared to python. > >> > > >> > Can some one point out what's wrong with my implementations? > >> > >> This isn't really a fair comparison. Map, IntMap, and Trie are > >> persistent data structures, and Python dictionaries are ephemeral. > >> (That is, when you "add" a key to a Map, you actually create a new one > >> that shares structure with the old one, and both can be used in > >> subsequent code. In Python, you would have to copy the dictionary.) > >> > > > > Strings, not ByteStrings. that's the difference. > > Is that in response to what I wrote, or to the original question? > > Speaking of ByteStrings and tries, has anyone implemented a Patricia > Trie for ByteStrings? I started putting one together a while back, but > I got distracted and never finished it. I started putting one together a while back but I got distracted and never finished it. I think its a couple of days polishing. -- Don From duncan.coutts at worc.ox.ac.uk Wed Nov 19 03:27:36 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Nov 19 03:20:38 2008 Subject: [Haskell-cafe] GHC 6.10.1 and cabal[-install] In-Reply-To: References: <200811181101.14630.g9ks157k@acme.softbase.org> <200811181423.12306.g9ks157k@acme.softbase.org> <1227043498.21705.36.camel@dell.linuxdev.us.dell.com> <492338CA.6090004@btinternet.com> Message-ID: <1227083256.21705.46.camel@dell.linuxdev.us.dell.com> On Tue, 2008-11-18 at 13:56 -0800, Jason Dagit wrote: > > Will Hackage one day provide a way to discover that one > package has been superceeded by another? > > Currently you can see when a newer version of the exact same > package exists, but (for example) take a took at how many > gazillion database packages there are up there. Which ones are > active? Which ones are obsolete? How can I tell?? > > This has come up before. As you can see here: > http://thread.gmane.org/gmane.comp.lang.haskell.cafe/46764 > > I think we just need someone (how about you!?) to start working on it. It's even easier than that! Someone has done it already :-) http://hackage.haskell.org/trac/hackage/ticket/261 Thu Aug 28 16:55:16 CEST 2008 Chry Cheng * Marking packages deprecated Fixes ticket no. 261 as discussed in its annotations. Packages with "deprecated" "true" are excluded from the package list. Packages with "superseded by" tags provide links to their superseding packages in the package page. The next bit is in making it easier for maintainers to set this data. Duncan From arne.d.h at gmail.com Wed Nov 19 03:57:01 2008 From: arne.d.h at gmail.com (Arne Dehli Halvorsen) Date: Wed Nov 19 03:51:08 2008 Subject: [Haskell-cafe] UArray Word16 Word32 uses twice as much memory as it should? Message-ID: <203d94090811190057h75326151nec8b69258f8668@mail.gmail.com> Hello, I am having an issue with these unboxed arrays. I have some code that creates this structure:: (Array Word16 (UArray Int Word32), Array Word16 (UArray Int Word8)), and I am finding that it uses about twice as much memory as I had anticipated. This tuple is returned strict, and I think I haven't left much room for other data remaining in memory. It should hold one Word8 and one Word32 for a data set of 100 million records, and it uses around 1 gigabyte. By my calculations, it should be half that. So I was wondering if I might have hit upon a 64-bit vs 32-bit issue. I compile with: ghc --make load05 -O1 -funbox-strict-fields -XBangPatterns -fvia-C (also tried with -O2, and without the -fvia-C) using the packaged version of ghc 6.10.1 on MacOSX 10.5.5 Grateful for any pointers, Arne D Halvorsen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081119/8ac15825/attachment.htm From duncan.coutts at worc.ox.ac.uk Wed Nov 19 04:04:01 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Nov 19 03:57:01 2008 Subject: [Haskell-cafe] Cabal and more than one version In-Reply-To: <42784f260811181653o7a8c1d35ydde860bf95f7b70a@mail.gmail.com> References: <42784f260811180148v7c48ed46p18132f44a377f8bf@mail.gmail.com> <1227043805.21705.42.camel@dell.linuxdev.us.dell.com> <42784f260811181653o7a8c1d35ydde860bf95f7b70a@mail.gmail.com> Message-ID: <1227085441.21705.51.camel@dell.linuxdev.us.dell.com> On Tue, 2008-11-18 at 16:53 -0800, Jason Dusek wrote: > In the ticket, someone says: > > True though I suspect it looks a bit weird to the > uninitiated. We know to read the conditional syntax as an > implication constraint which can be applied in either > direction but I suspect many people read it in a directed > functional way. > > Does that mean you don't have to actually set 'splitBase' > explicitly? No, that is the point. You do not have to. The choice for the flag is completely determined automatically by the version of the base package that is chosen. Because in this construct the flag choice is completely determined by another choice by the user/environment (the version of a package) then we do not really need a flag at all. That's why we're considering adding some syntactic sugar for these kinds of common cases. But it really would be just syntactic sugar. The semantics are sufficiently powerful already. Duncan From wss at cs.nott.ac.uk Wed Nov 19 04:04:12 2008 From: wss at cs.nott.ac.uk (Wouter Swierstra) Date: Wed Nov 19 03:58:19 2008 Subject: [Haskell-cafe] Monadic bind with associated types + PHOAS? In-Reply-To: <2f9b2d30811182039n5830b80fre5ae07456a97a0a5@mail.gmail.com> References: <2f9b2d30811182039n5830b80fre5ae07456a97a0a5@mail.gmail.com> Message-ID: Hi Ryan, On 19 Nov 2008, at 04:39, Ryan Ingram wrote: > In HOAS, a lambda expression in the target language is represented > by a function in the source language: > >> data ExpE t where >> ApE :: ExpE (a -> b) -> ExpE a -> ExpE b >> LamE :: (ExpE a -> ExpE b) -> ExpE (a -> b) > > But without a way to inspect the function inside LamE, you can't get > back to the "source code". You end up adding special constructors for > "Primitive" or "Variable" to let you do something with the resultant > structure, which leads to the expression language containing "unsafe" > constructors which need to be hidden. There's a perfectly legitimate way to incorporate free variables in your expression data type, without sacrificing type safety. You just need to parametrise your expression type by the context: > data Exp g t where > App :: Exp g (a -> b) -> Exp g a -> Exp g b > Lam :: (Exp g a -> Exp g b) -> Exp g (a -> b) > Var :: Var g a -> Exp g a > > data Var g a where > Top :: Var (a,g) a > Pop :: Var a g -> Var a (b, g) I wouldn't call this "unsafe" (or at least no more unsafe than HOAS). Note that in particular "Exp Empty a" correspond to closed terms, where Empty denotes the empty type. Secondly, you can always turn a HOAS Exp into non-HOAS expression. Essentially, you map applications to applications, etc. The only interesting case deal with lambda abstractions - there you need to generate a fresh variable name, apply the function to the fresh variable, and continue traversing the resulting expression. You might be interested in a tutorial Andres Loeh, Conor McBride, and I wrote about implementing a dependently typed lambda calculus: http://www.cs.nott.ac.uk/~wss/Publications/Tutorial.pdf The "quote" function in Figure 7 gives the code. > Does anyone think this is a direction worth pursuing? I'm not convinced yet. The problem is that there's no best way to handle binding. HOAS is great for some things (you don't have to write substitution), but annoying for others (optimisations or showing code). From your message, I couldn't understand why you want to use monads/do-notation to handle binding. Care to elaborate? All the best, Wouter From donn at avvanta.com Wed Nov 19 04:23:02 2008 From: donn at avvanta.com (Donn Cave) Date: Wed Nov 19 04:17:10 2008 Subject: [Haskell-cafe] FFI and returning structs Message-ID: <20081119092302.4523DF3951@mail.avvanta.com> Quoth Maurcio : | I have not found examples of this in documentation | or hackage packages: how can I deal with funcions | returning not pointers to structs but structs | thenselves? | | struct example {... | | example function_name (... | | My intuition said I could try a data declaration | that is a properly done instance of Storable, and | then use that. | | data Example = ... | | instance Storable Example where ... | | But it seems I was wrong. Eh! probably not wrong - the problem is not how the data looks, but where it is. If it were my problem, I would try a wrapper function that returns the same value as an argument - e.g., if you have struct X f(), then void f_(struct X *x) { *x = f(); } ... so your wrapper will look like ccall "f_" f :: Ptr X -> IO () instead of ccall "f" f :: IO X Ironically, that's actually just what the original function is doing - cf. "struct return convention", where the caller allocates space and passes a pointer as a hidden parameter. But you can't just declare it that way, because the original f bumps the stack pointer on return (you may see "ret $4" in the assembly code, on Intel hardware) Try to compile the wrapper with the same compiler that compiled the original function. I'm really just guessing that your Haskell compiler doesn't understand or perfectly handle this particular C wart. If my suggestion doesn't work, I may have guessed wrong. Donn From g9ks157k at acme.softbase.org Wed Nov 19 04:28:35 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Nov 19 04:22:43 2008 Subject: [Haskell-cafe] GHC 6.10.1 and cabal[-install] In-Reply-To: <1227043498.21705.36.camel@dell.linuxdev.us.dell.com> References: <200811181101.14630.g9ks157k@acme.softbase.org> <200811181423.12306.g9ks157k@acme.softbase.org> <1227043498.21705.36.camel@dell.linuxdev.us.dell.com> Message-ID: <200811191028.35559.g9ks157k@acme.softbase.org> Am Dienstag, 18. November 2008 22:24 schrieben Sie: > > > How do I install and configure it so that it is integrated best with > > > GHC 6.10.1? For example, should cabal use some directory in the GHC > > > tree to place compiled packages in? > > The defaults for user or global should be fine. There is no need to put > additional packages into the ghc install tree, indeed I would recommend > against doing that. Hmm, /usr/local is not so fine for me since it makes packages hard(er) to uninstall. I use stow (). > > Cabal wants to place package info in $HOME/.cabal. However, I want to > > install packages globally with sudo. So I want to have a global package > > cache. Is there a common directory to be used for that or is > > cabal[-install] only for per-user installations? > > It can do per-user or global. Per-user is the default. > > If you want to do the build as user and just the install as root then > you can use the --global --root-cmd=sudo options. If you want to use > this every time then you can set that in the ~/.cabal/config file. I want the package cache etc. global. The problem is that with sudo, cabal still uses $HOME/.cabal where $HOME is the home directory of the ordinary user (not the one of root). Does --global change the directory for cabal configuration and the package cache to something different than $HOME/.cabal? > The cabal user guide lists the default install directories for global > and user installs. Okay, I looked at the cabal-install docs. And the only doc seems to be the output of cabal with the --help option. Best wishes, Wolfgang From jason.dusek at gmail.com Wed Nov 19 05:15:06 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed Nov 19 05:09:13 2008 Subject: [Haskell-cafe] Cabal and more than one version In-Reply-To: <1227085441.21705.51.camel@dell.linuxdev.us.dell.com> References: <42784f260811180148v7c48ed46p18132f44a377f8bf@mail.gmail.com> <1227043805.21705.42.camel@dell.linuxdev.us.dell.com> <42784f260811181653o7a8c1d35ydde860bf95f7b70a@mail.gmail.com> <1227085441.21705.51.camel@dell.linuxdev.us.dell.com> Message-ID: <42784f260811190215j74050250t29022b272e2d67f5@mail.gmail.com> Duncan Coutts wrote: > Jason Dusek wrote: > > In the ticket, someone says: > > > > True though I suspect it looks a bit weird to the > > uninitiated. We know to read the conditional syntax as an > > implication constraint which can be applied in either > > direction but I suspect many people read it in a directed > > functional way. > > > > Does that mean you don't have to actually set 'splitBase' > > explicitly? > > No, that is the point. You do not have to. The choice for the > flag is completely determined automatically by the version of > the base package that is chosen. When you say "chosen" is that the same as "detected"? With 6.10, both versions of base are available -- what happens then? The environment chooses the latest one? -- _jsn From ketil at malde.org Wed Nov 19 05:56:09 2008 From: ketil at malde.org (Ketil Malde) Date: Wed Nov 19 05:50:17 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <4922AB27.8030602@daimi.au.dk> (Tillmann Rendel's message of "Tue\, 18 Nov 2008 12\:46\:47 +0100") References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <4922AB27.8030602@daimi.au.dk> Message-ID: <87bpwcf0hi.fsf@malde.org> Tillmann Rendel writes: > Why should a Haskell hash table need more memory then a Python hash > table? I've heard that Data.HashTable is bad, so maybe writing a good > one could be an option. One problem is that Haskell collections are lazy by default. I'm aware of a few use cases where laziness lets you formulate a very elegant recursive population of a collection, but I think that in general, strictness is what you want, and further, that if you want lazy, you store your data as one-tuples: data Lazy a = Lazy a (If there's a workaround/solution in the other direction, I'd really like to hear it). I'm therefore tempted to suggest that collections should be strict by default, and in particular, that there should be strict arrays for arbitrary types, not just the ones that happen to be unboxable. Unboxing should be an optimization for (some) strict arrays. -k -- If I haven't seen further, it is by standing in the footprints of giants From tobias.bexelius at avalanchestudios.se Wed Nov 19 06:01:03 2008 From: tobias.bexelius at avalanchestudios.se (Tobias Bexelius) Date: Wed Nov 19 05:55:11 2008 Subject: [Haskell-cafe] Pattern matching on numbers? In-Reply-To: <49a77b7a0811181600keeb9de2j126416e6d3ad1cb@mail.gmail.com> References: <2f9b2d30811181544h45cc5cd0vdeed0047af8d7356@mail.gmail.com> <49a77b7a0811181600keeb9de2j126416e6d3ad1cb@mail.gmail.com> Message-ID: <698E8783CC407F4EB0DC9E994B6D4540D8BC0A@nut.avalanchestudios.se> Yes, fromInteger and == is used for pattern matching on numbers. However, on GHC you can use -XNoImplicitPrelude to make it use whatever fromInteger and == that's in scope (without any Num or Eq). Eg. if == is a method of MyEq class and fromInteger is a method of MyNum, and MyNum doesn't inherit MyEq, then the type of this function f 0 = "" f x = 'e' : f (x-1) Will be inferred as (MyEq a, MyNum a) => a -> String /Tobias -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of David Menendez Sent: den 19 november 2008 01:00 To: Henning Thielemann Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Pattern matching on numbers? On Tue, Nov 18, 2008 at 6:56 PM, Henning Thielemann wrote: > > On Tue, 18 Nov 2008, Ryan Ingram wrote: > >> How does this work? >> >>> fac n = case n of >>> 0 -> 1 >>> _ -> n * fac (n-1) >> >> ghci> :t fac >> fac :: (Num t) => t -> t >> >> The first line of "fac" pattern matches on 0. So how does this work >> over any value of the Num typeclass? I know that the "1" on the rhs >> of fac are replaced with (fromInteger 1), but what about numeric >> literals in patterns? Does it turn into a call to (==)? > > As far as I know, yes. It is even possible to trap into an error on > pattern matching this way if fromInteger generates an 'undefined'. As I understand it, the use of (==) in numeric pattern matching is why Num requires Eq. -- Dave Menendez _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe From ryani.spam at gmail.com Wed Nov 19 06:16:24 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Nov 19 06:10:31 2008 Subject: [Haskell-cafe] Monadic bind with associated types + PHOAS? In-Reply-To: References: <2f9b2d30811182039n5830b80fre5ae07456a97a0a5@mail.gmail.com> Message-ID: <2f9b2d30811190316o7d24cfccl235fafcf26d17a73@mail.gmail.com> On Wed, Nov 19, 2008 at 1:04 AM, Wouter Swierstra wrote: > I'm not convinced yet. The problem is that there's no best way to handle > binding. HOAS is great for some things (you don't have to write > substitution), but annoying for others (optimisations or showing code). PHOAS solves "showing code" quite nicely, in my opinion. I haven't tried to write a real optimizer using it yet. It's probably better to convert to a better intermediate representation and then back when you're done. The nice thing about HOAS, in my opinion, is not that it's a good representation of a language; rather it is that the syntax for *writing* it in your code is much nicer than the explicit variable references needed otherwise, because you have lifted part of the syntax into the host language. > From your message, I couldn't understand why you want to use monads/do-notation > to handle binding. Care to elaborate? Sure; I guess I should explain the motivation a bit. I really like the syntax for do-notation. And I really like how great Haskell is as writing embedded languages, a lot of which comes from the "programmable semicolon" that monadic bind gives you. But there's no equivalent "programmable variable bind", or "programmable function application"; both are generalizations of do-notation that would be useful for embedded languages. So I have been thinking about what makes variable binding special. What is it that we get from a variable bind? How can we create a structure that allows one to program & control the results of the binding values to variables? This has many uses in embedded languages: 1) We can observe sharing; solving this in DSLs in Haskell usually leads to really ugly syntax. 2) We can write interpretation functions that can examine all possible execution paths; this is basically "introspection on functions". This lets us do whole program optimization or other transformations on the result of the monadic code. (2) is usually solved via arrows, although "arr" makes a true solution quite difficult. I don't know of an elegant solution for (1) at all. Do you have any ideas along these lines? -- ryan From claus.reinke at talk21.com Wed Nov 19 06:50:13 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Nov 19 06:44:23 2008 Subject: strict collections via types (was: [Haskell-cafe] implementing python-style dictionary in Haskell) References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com><4922AB27.8030602@daimi.au.dk> <87bpwcf0hi.fsf@malde.org> Message-ID: > One problem is that Haskell collections are lazy by default. I'm > aware of a few use cases where laziness lets you formulate a very > elegant recursive population of a collection, but I think that in > general, strictness is what you want, While I strongly agree with the gist of your post, I never liked this particular kind of argument - different people have different needs. > and further, that if you want lazy, you store your data as > one-tuples: data Lazy a = Lazy a > > (If there's a workaround/solution in the other direction, I'd really > like to hear it). That is the crunch point. If we can't choose between strict and non-strict usage, the default becomes the only option, and it simply doesn't fit all use cases. Workarounds are currently somewhat random: - for indexed collections (which tend to be strict in the keys), one can use strict pairs when building from lists of pairs, but that doesn't work for all operations (at least not with the current APIs) - some collections, for a few operations, provide strict alternatives, but that doesn't cover much of the API, and isn't even consistent over variations of the same kind of collection - for some types, strict alternatives are provided as separate packages That means that not only are the usage patterns different, for the same problem, in different contexts (making switching types harder), but one can only get the solutions for some operations in some types: one is limited to the spartan and incomplete subset of the data type API that supports switching between strict and non-strict (check which operations in Data.Map support both modes, then check what happens when you want to move from Data.Map to Data.IntMap..). Not to mention that the strict alternatives aren't made obvious (you have to know that you should look for '-ed variants of operation names to get them, sometimes; that goes back all the way to the popular foldl with strict accumulator trap) and are documented in names instead of specified in types. Using a single set of packages and operations, with standardized ways of instantiating a collection/type as either strict or non-strict, would be much better (well, usable, for a start;-), IMHO. - using a strict default, optionally disabled via non-strict one-tuples, sounds workable (perhaps the one-tuple should be standardized, to give the compiler an indication that this is really an annotation, and to get similar benefits as from newtype deriving). - using strictness annotations in types seems simpler, but has the drawback that the annotations are really not part of the types; types just happen to be a nice place to put annotations that amount to invariants ('!t' in some context saying: "I always want whnf in this position, not unevaluated thunks") that the compiler can use for modifying strictness analysis and code generation. - an in-between step might be to parameterize collections by a type constructor, with two pre-defined constructors ("Strict" and "Id") that effectively play the role of annotations while being proper parts of types (type constructors), thereby documenting intent and enabling (pre-)specialization of code without creating programming or efficiency overheads (at least not for the library author - not so sure about library users). One important point is composition of contexts: if one wants, say, a "Data.Map.Map Key (Data.Map.Map Key type)", it should be possible to specify that one wants both Maps element-strict, and hence the composed structure strict in "type", without obfuscating the code with 'seq's or 'Lazy's all over the place. I can see that working with an annotation + code-generation/specialization approach, but how close would a type-tag approach come to supporting this? > I'm therefore tempted to suggest that collections should be > strict by default, and in particular, that there should be strict > arrays for arbitrary types, not just the ones that happen to be > unboxable. Unboxing should be an optimization for (some) strict > arrays. Another suggestion I find myself agreeing with: when I'm looking for strict variants of standard data types, unboxing is a natural follow-on optimization, but if unboxing isn't possible, that shouldn't keep me from getting the benefits of strictness where I need them. Claus From briqueabraque at yahoo.com Wed Nov 19 07:49:28 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Wed Nov 19 07:43:44 2008 Subject: [Haskell-cafe] Re: FFI and returning structs In-Reply-To: <20081119092302.4523DF3951@mail.avvanta.com> References: <20081119092302.4523DF3951@mail.avvanta.com> Message-ID: >> I have not found examples of this in documentation or hackage >> packages: how can I deal with funcions returning not pointers >> to structs but structs thenselves? >> >> struct example {... >> >> example function_name (... >> >> (...) > > (...) > > If it were my problem, I would try a wrapper function that > returns the same value as an argument - e.g., if you have struct > X f(), then > > void f_(struct X *x) > { > *x = f(); > } > > (...) Ironically, that's actually just what the original > function is doing - cf. "struct return convention", where the > caller allocates space and passes a pointer as a hidden > parameter. (...) Can I be sure things always goes like that? I remember reading somewhere that if, for instance, a struct is smaller in size than a pointer (like a struct made of three chars), the struct could be returned by itself. Also, why Haskell FFI do not automate that? As long as it is Storable data, can't it get the pointer and 'peek' it for me? Thanks, Maur?cio From marlowsd at gmail.com Wed Nov 19 08:43:28 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 19 08:37:38 2008 Subject: [Haskell-cafe] Re: Can't figure out source of race condition when using System.Process In-Reply-To: <490EF365.1010208@xaph.net> References: <490DB2E4.3090105@xaph.net> <490EF365.1010208@xaph.net> Message-ID: <49241800.2010809@gmail.com> Rafal Kolanski wrote: > > Bryan O'Sullivan wrote: >> What is the "it" that segfaults? The Haskell program shouldn't, at least. > > The Haskell program. It does so rarely, however, and I'm unable to > reproduce it with any consistency, only enough to notice something is > wrong with what I've written. > Upon closer examination my code also returns an error exit code for > subprocesses that should've succeeded (pdflatex, but once in a blue moon > also pstoedit) similarly rarely. > >> That said, your code for reading from child processes is wrong. You >> should read all of a child's output strictly (i.e. hGetContents alone >> will not do the trick) before you wait for its exit status. Your >> current scheme reverses this order, and there is hence no guarantee >> that it will read anything from the defunct child process. There's >> some possibility that this might be the cause of your segfault, which >> to me would suggest the presence of a bug in the runtime system. > > Well, if there's a bug in the runtime system, I'll try to make sure I > can reproduce it before filing a report. Even if the bug only happens once every few runs, please report it anyway. (I've been chasing a lot of bugs like that recently :-). Cheers, Simon From marlowsd at gmail.com Wed Nov 19 08:51:55 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 19 08:46:05 2008 Subject: [Haskell-cafe] Re: Automatic parallelism in Haskell, similar to "make -j4"? In-Reply-To: <1976563267.20081105105425@gmail.com> References: <9c72296b0811021528w596e07b4pbd8ed46cdd7ef6c6@mail.gmail.com> <1976563267.20081105105425@gmail.com> Message-ID: <492419FB.6050206@gmail.com> Bulat Ziganshin wrote: > Hello Chad, > > Wednesday, November 5, 2008, 6:34:01 AM, you wrote: > >> ghc --make -j4 Foo.hs > > afair, it was implemented and not shown speed improvements. ask Simon We did get speed improvements, it was the main case study for the initial implementation of shared-memory parallelism in GHC. See http://www.haskell.org/~simonmar/bib/multiproc05_abstract.html However, due to the way GHC is structured internally (it has some global caches updated using unsafePerformIO!) the parallel make implementation was quite fragile, and wasn't suitable for incorporating into GHC proper. It's certainly possible, but we need to think carefully about how to make these caches multi-thread-safe. Cheers, Simon From wss at Cs.Nott.AC.UK Wed Nov 19 10:20:22 2008 From: wss at Cs.Nott.AC.UK (Wouter Swierstra) Date: Wed Nov 19 10:15:00 2008 Subject: [Haskell-cafe] The Monad.Reader - Issue 12: SoC Special Message-ID: <4709FE40-08C3-4E85-8429-6A7FB67C6D2E@Cs.Nott.AC.UK> I am pleased to announce that a new issue of The Monad.Reader is now available: http://www.haskell.org/haskellwiki/The_Monad.Reader Issue 12 is another Summer of Code special and consists of the following three articles: * Max Bolingbroke Compiler Development Made Easy * Roman Cheplyaka How to Build a Physics Engine * Neil Mitchell Hoogle Overview The Monad.Reader is a quarterly magazine about functional programming. It is less formal than a journal, but more enduring than a wiki page or blog post. If you'd like to write something for the next issue of The Monad.Reader, please get in touch. The deadline for the next issue will be February 13th. Looking forward to your submissions, Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081119/c37931c5/attachment.htm From bulat.ziganshin at gmail.com Wed Nov 19 12:02:09 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Nov 19 11:56:28 2008 Subject: [Haskell-cafe] UArray Word16 Word32 uses twice as much memory as it should? In-Reply-To: <203d94090811190057h75326151nec8b69258f8668@mail.gmail.com> References: <203d94090811190057h75326151nec8b69258f8668@mail.gmail.com> Message-ID: <1303728647.20081119200209@gmail.com> Hello Arne, Wednesday, November 19, 2008, 11:57:01 AM, you wrote: > finding that it uses about twice as much memory as I had anticipated. it may be 1) GC problem (due to GC haskell programs occupies 2-3x more memory than actually used) 2) additional data (you not said how long each small array. you should expect 10-30 additional bytes used for every array) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jgbailey at gmail.com Wed Nov 19 12:11:10 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Wed Nov 19 12:05:16 2008 Subject: [Haskell-cafe] streaming translation using monads In-Reply-To: <38C9CD80-7FFB-43EB-9970-258A5ACEB8A0@gmail.com> References: <38C9CD80-7FFB-43EB-9970-258A5ACEB8A0@gmail.com> Message-ID: On Tue, Nov 18, 2008 at 6:23 PM, Warren Harris wrote: > I am working on a query language translator, and although I feel that a > monadic formulation would work well for this application, I've stumbled on a > number of questions and difficulties that I thought the knowledgeable people > here might be able to help me with. > HaskellDB takes a similar approach. It's "Query" monad allows you to build queries which are then translated to SQL by a "runQuery" function. Could your bind operation collect the 'input' expressions and then output them all at once via a "runTranslation" function? Do you have to do in-place translation? Justin From donn at avvanta.com Wed Nov 19 12:11:28 2008 From: donn at avvanta.com (Donn Cave) Date: Wed Nov 19 12:05:35 2008 Subject: [Haskell-cafe] Re: FFI and returning structs Message-ID: <20081119171128.6ECF2276CC2@mail.avvanta.com> Quoth Maurcio : |> (...) Ironically, that's actually just what the original |> function is doing - cf. "struct return convention", where the |> caller allocates space and passes a pointer as a hidden |> parameter. (...) | | Can I be sure things always goes like that? I remember reading | somewhere that if, for instance, a struct is smaller in size than | a pointer (like a struct made of three chars), the struct could be | returned by itself. I think you can be reasonably sure it doesn't always work that way! But if you're interested, you can see what the compiler does with that smaller struct, looking at the assembly code it generates. I'm no Intel programmer, but if my test function uses a parameter, I can see that the parameter is found at an offset, compared to the same function returning a plain scalar value. So - yes, the struct value is returned in a register - but the convention is also observed, with the hidden parameter. Using gcc for Intel 80386 family CPU. Maybe later I will see how it works on AMD64. | Also, why Haskell FFI do not automate that? As long as it is | Storable data, can't it get the pointer and 'peek' it for me? I can't speak for the FFI authors, and note that I'm not even saying that it can't do this. Your inquiry was rather short on details about what happened, and anyway it's only convenient for me to try it with NHC, which may not be the compiler you're using. But if it were up to me, I doubt that I would support this (struct return), since it's rare, at best it adds to the difficulty of supporting different hardware platforms and compilers, and it's easy to work around. Donn From warrensomebody at gmail.com Wed Nov 19 12:59:22 2008 From: warrensomebody at gmail.com (Warren Harris) Date: Wed Nov 19 12:53:34 2008 Subject: [Haskell-cafe] streaming translation using monads In-Reply-To: <068EC4D2-91A5-4071-9719-1D7C9CA5CCB6@ece.cmu.edu> References: <38C9CD80-7FFB-43EB-9970-258A5ACEB8A0@gmail.com> <068EC4D2-91A5-4071-9719-1D7C9CA5CCB6@ece.cmu.edu> Message-ID: On Nov 18, 2008, at 6:53 PM, Brandon S. Allbery KF8NH wrote: > On 2008 Nov 18, at 21:23, Warren Harris wrote: >> However, each of the clauses is actually an output routine to send >> the expression that it denotes to a remote server, and a parser for >> receiving the results. Since a clause is really a pair of >> operations, it doesn't seem possible to formulate a monad that will >> compose all the output routines together and compose all the input >> routines together in one shot. (Note that the variables in the >> above code (v1, v2) represent inputs to be received from the remote >> server -- all outputs are packaged into the clause expressions >> themselves and are effectively literals.) > > > Have you considered using arrows instead? I'm not that familiar with arrows, but have just looked at some papers by Hughes and Paterson. It appears that unlike monads, the right-hand side of the arrow operator is not a function, and as such could be used to define a pairwise stream sequencing operator for my particular case. Are there any specific references that show something like this, e.g. for implementing network protocols? (I'm still trying to get my head around the basics of arrows.) Thanks, Warren From briqueabraque at yahoo.com Wed Nov 19 13:01:08 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Wed Nov 19 12:55:24 2008 Subject: [Haskell-cafe] Re: Begginer question about alignment in Storable In-Reply-To: References: Message-ID: > If you are using hsc2hs (if you are using Cabal this is easy; just > rename the file to *.hsc and Cabal will take care of the rest), then > there is a macro for making this easier and so you don't have to think > about it. (...) Well, after reading FFI addendum, I'm using my loyal text editor. Am I supposed to use something else? Is there something a tool like hsc2hs or cabal setup can do that is more portable than what I could write myself? Where should I learn about that? Thanks, Maur?cio From ccshan at post.harvard.edu Wed Nov 19 13:03:40 2008 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Wed Nov 19 13:13:24 2008 Subject: [Haskell-cafe] Re: Monadic bind with associated types + PHOAS? References: <2f9b2d30811182039n5830b80fre5ae07456a97a0a5@mail.gmail.com> <2f9b2d30811190316o7d24cfccl235fafcf26d17a73@mail.gmail.com> Message-ID: Ryan Ingram wrote in article <2f9b2d30811190316o7d24cfccl235fafcf26d17a73@mail.gmail.com> in gmane.comp.lang.haskell.cafe: > I really like the syntax for do-notation. And I really like how great > Haskell is as writing embedded languages, a lot of which comes from > the "programmable semicolon" that monadic bind gives you. AFAICT, standard Haskell 98 already gives you the ability to express binding and sharing in PHOAS, except not using do-notation: class Symantics repr where lam :: (repr a -> repr b) -> repr (a -> b) app :: repr (a -> b) -> repr a -> repr b add :: repr Int -> repr Int -> repr Int int :: Int -> repr Int let_ :: Symantics repr => repr a -> (repr a -> repr b) -> repr b let_ e body = app (lam body) e testSharing :: Symantics repr => repr Int testSharing = let_ (add (int 3) (int 4)) (\x -> add x x) Oleg has already noted that you can nicely express the showing, optimization (such as partial evaluation), and transformation (such as to CPS) of embedded code in this framework. I agree with him and you that this representation is a promising direction to explore. All that's missing in standard Haskell 98, then, is the ability to use do-notation: (>>=) = let_ testSharing = do x <- add (int 3) (int 4) add x x But -XNoImplicitPrelude in GHC 6.10 is supposed to enable it, no? -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig 2008-11-20 Universal Children's Day http://unicef.org/ 1948-12-10 Universal Declaration of Human Rights http://everyhumanhasrights.org From arne.d.h at gmail.com Wed Nov 19 13:33:45 2008 From: arne.d.h at gmail.com (Arne Dehli Halvorsen) Date: Wed Nov 19 13:27:55 2008 Subject: [Haskell-cafe] UArray Word16 Word32 uses twice as much memory as it should? In-Reply-To: <1303728647.20081119200209@gmail.com> References: <203d94090811190057h75326151nec8b69258f8668@mail.gmail.com> <1303728647.20081119200209@gmail.com> Message-ID: <49245C09.500@gmail.com> Bulat Ziganshin wrote: > Hello Arne, > > Wednesday, November 19, 2008, 11:57:01 AM, you wrote: > > >> finding that it uses about twice as much memory as I had anticipated. >> > > Hello, and thank you for your reply. > it may be > 1) GC problem (due to GC haskell programs occupies 2-3x more memory > than actually used) > I wasn't aware of that - but it should be possible to trigger a GC after loading a whole lot of data? > 2) additional data (you not said how long each small array. you should > expect 10-30 additional bytes used for every array) > The arrays represent the netflix data set: 100 000 000 ratings, given for 17770 films. For each the films, I want to hold (on average, roughly) 2000 ratings, held as one person id (32-bit) and one rating (8-bit), in the respctive arrays. (In addition, I want to be able to load the inversion of this data: for all persons, I want to hold their ratings in a similar way: 16-bit film id, 8-bit rating. There are 480000 persons, so this should be on average 200 entries per person. I have coded a few approaches to inverting this, but I can't allocate the array before traversing the data, because I don't know the sizes. How can one go about inverting this data in memory? It seems that any kind of laziness will fill the whole memory before I have traversed the whole set - and if I use several accumArrays, it seems that it will hold the whole uncompacted dataset in memory between accumArrays. Ideally I want to hold all ratings as well as statistics for all films, and the same for all the persons - and then have room to spare for running an algorithm... Best regards, Arne D Halvorsen From warrensomebody at gmail.com Wed Nov 19 14:50:13 2008 From: warrensomebody at gmail.com (Warren Harris) Date: Wed Nov 19 14:44:23 2008 Subject: [Haskell-cafe] streaming translation using monads In-Reply-To: References: <38C9CD80-7FFB-43EB-9970-258A5ACEB8A0@gmail.com> Message-ID: On Nov 19, 2008, at 9:11 AM, Justin Bailey wrote: > On Tue, Nov 18, 2008 at 6:23 PM, Warren Harris > wrote: >> I am working on a query language translator, and although I feel >> that a >> monadic formulation would work well for this application, I've >> stumbled on a >> number of questions and difficulties that I thought the >> knowledgeable people >> here might be able to help me with. >> > > HaskellDB takes a similar approach. It's "Query" monad allows you to > build queries which are then translated to SQL by a "runQuery" > function. Could your bind operation collect the 'input' expressions > and then output them all at once via a "runTranslation" function? Thanks for pointing this out. I had looked at Leigen & Meijer's paper a while back which describes this, and in one branch of my code taken a very similar approach by using an abstract datatype with phantom types to represent the target language. However, I had concluded (perhaps incorrectly) that the technique was not amenable to streaming the results back to the client without first constructing an in-memory list with a universal type representing the values returned. Now perhaps the in-memory list part was a bad conclusion since the queries can be decorated with translation functions capable of streaming the results out to another channel. However, the use of a universal type for the values would still seem to be required since there is no way to implement type-indexed values when the queries themselves are expressed as an abstract datatype rather than as functions. Am I overlooking something? As an aside, maybe I've been unduly concerned with wrapping the raw values in a universal type since I've found that in most cases for my target language I must deal with the possibility of null results, and must wrap most values in a Maybe type anyway. So I must pay the allocation cost in most cases... and with phantom types perhaps I can avoid the possibility of dynamic type errors due to unexpected data or ill-formed target queries. > Do > you have to do in-place translation? Not sure I follow. Warren From jgbailey at gmail.com Wed Nov 19 15:19:17 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Wed Nov 19 15:13:24 2008 Subject: [Haskell-cafe] streaming translation using monads In-Reply-To: References: <38C9CD80-7FFB-43EB-9970-258A5ACEB8A0@gmail.com> Message-ID: On Wed, Nov 19, 2008 at 11:50 AM, Warren Harris wrote: > Now perhaps the in-memory list part was a bad conclusion since the queries > can be decorated with translation functions capable of streaming the results > out to another channel. However, the use of a universal type for the values > would still seem to be required since there is no way to implement > type-indexed values when the queries themselves are expressed as an abstract > datatype rather than as functions. Am I overlooking something? > If the type of the input determines the type of the output, and the type of the input can be determined statically, then I think you are overlooking this technique. But if your application requires that each input expression be sent to the remote client before type information can be determined, then you are right. In the case of HaskellDB, each operator/term in the Query monad enriches the type information available. Of course, that enrichment happens at compile time and occurs via type inference. For example, assuming two tables T1 and T2, with columns T1col and T2col, this expression: simpleQuery = do t1 <- table T1 t2 <- table T2 restrict ( .. some expression ...) project (t1 ! T1col1 # t2 ! T2col1) Gives a type similar to Query (RecCons T1Col1 Int (RecCons T2 Col2 Int RecNil)). RecCons and RecNil are types that allow a list to be built at the type level. The list carries the column names and types in the resulting projection. The type information is used to ensure queries only refer to columns that exist, datatypes are compared sensibly, etc. If in your case you can build that kind of structure based purely on the "input language" operators/terms, then it seems you could build the entire "output expression" in one shot. But again, if input and output have to be interleaved then I think you are stuck. Justin From ccshan at post.harvard.edu Wed Nov 19 15:18:31 2008 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Wed Nov 19 15:54:29 2008 Subject: [Haskell-cafe] Re: streaming translation using monads References: <38C9CD80-7FFB-43EB-9970-258A5ACEB8A0@gmail.com> Message-ID: Warren Harris wrote in article in gmane.comp.lang.haskell.cafe: > However, the use of a > universal type for the values would still seem to be required since > there is no way to implement type-indexed values when the queries > themselves are expressed as an abstract datatype rather than as > functions. Am I overlooking something? You might find inspiration in the fact that printf and scanf can be expressed in ML/Haskell without any fancy type-system features. http://www.brics.dk/RS/98/12/ http://cs.nyu.edu/zheyang/papers/YangZ--ICFP98.html http://article.gmane.org/gmane.comp.lang.haskell.general/16409 http://www.itu.dk/people/mir/typesafepatterns.pdf Credits to: Olivier Danvy, Zhe Yang, Kenichi Asai, Oleg Kiselyov, Morten Rhiger. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig 2008-11-20 Universal Children's Day http://unicef.org/ 1948-12-10 Universal Declaration of Human Rights http://everyhumanhasrights.org From andrewcoppin at btinternet.com Wed Nov 19 16:37:37 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Nov 19 16:31:42 2008 Subject: [Haskell-cafe] Deprecated packages In-Reply-To: References: <200811181101.14630.g9ks157k@acme.softbase.org> <200811181423.12306.g9ks157k@acme.softbase.org> <1227043498.21705.36.camel@dell.linuxdev.us.dell.com> <492338CA.6090004@btinternet.com> <49233B07.7000709@btinternet.com> Message-ID: <49248721.4030409@btinternet.com> Jason Dagit wrote: > > > On Tue, Nov 18, 2008 at 2:03 PM, Jason Dagit > wrote: > > > > On Tue, Nov 18, 2008 at 2:00 PM, Andrew Coppin > > > wrote: > > Jason Dagit wrote: > > > Will Hackage one day provide a way to discover that one > package > has been superceeded by another? > > Currently you can see when a newer version of the exact > same > package exists, but (for example) take a took at how many > gazillion database packages there are up there. Which > ones are > active? Which ones are obsolete? How can I tell?? > > > This has come up before. As you can see here: > http://thread.gmane.org/gmane.comp.lang.haskell.cafe/46764 > > I think we just need someone (how about you!?) to start > working on it. > > > What do I need to do? Just obtain the Hackage source code and > submit a Darcs patch or something? Or is it harder than that? > > > A darcs patch should work. If you look in the thread I linked to > you'll see this message by Thomas M. DuBuisson: > > > By copy and paste, my apologies: > http://article.gmane.org/gmane.comp.lang.haskell.cafe/46773 Hackage ticket #261 appears to contain the required patch already. http://hackage.haskell.org/trac/hackage/ticket/261 From dm.maillists at gmail.com Wed Nov 19 16:41:59 2008 From: dm.maillists at gmail.com (Daniel McAllansmith) Date: Wed Nov 19 16:36:19 2008 Subject: [Haskell-cafe] GHC 6.10.1 and cabal[-install] In-Reply-To: <1227083256.21705.46.camel@dell.linuxdev.us.dell.com> References: <200811181101.14630.g9ks157k@acme.softbase.org> <1227083256.21705.46.camel@dell.linuxdev.us.dell.com> Message-ID: <200811201041.59293.dm.maillists@gmail.com> On Wed, 19 Nov 2008 21:27:36 Duncan Coutts wrote: > It's even easier than that! Someone has done it already :-) > > http://hackage.haskell.org/trac/hackage/ticket/261 > > Thu Aug 28 16:55:16 CEST 2008 Chry Cheng > * Marking packages deprecated > Fixes ticket no. 261 as discussed in its annotations. Packages with > "deprecated" "true" are excluded from the package list. Packages with > "superseded by" tags provide links to their superseding packages in the > package page. Does "excluded from the package list" mean that deprecated packages won't show up on http://hackage.haskell.org/packages/archive/pkg-list.html ? If so, how does one go about finding and downloading deprecated packages? Rely on the search function to find the package page? How do you get a comprehensive list of the deprecated packages that have existed? Perhaps there should be a deprecated-pkg-list.html page. If being superseded implies deprecation this page is also where the superseded packages would go, with appropriate supersedes/superseded-by links between them. From duncan.coutts at worc.ox.ac.uk Wed Nov 19 17:35:46 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Nov 19 17:28:44 2008 Subject: Fwd: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> <20081118205238.GD2422@scytale.galois.com> Message-ID: <1227134146.21705.88.camel@dell.linuxdev.us.dell.com> On Tue, 2008-11-18 at 22:42 +0100, Alberto G. Corona wrote: > sorry, Dons, > > ---------- Forwarded message ---------- > From: Alberto G. Corona > Date: 2008/11/18 > Subject: Re: [Haskell-cafe] implementing python-style dictionary in > Haskell > To: Don Stewart > > > By the way byteStrings are wonderful, but, it isn?t true that > byteStrings are not so fast for managing short strings, for example > keys ? For short strings they're fast to use but not fast to construct and not very memory efficient. There's 20 bytes overhead per ByteString. A packed string type optimised for short strings would make different design decisions. Duncan From warrensomebody at gmail.com Wed Nov 19 18:33:14 2008 From: warrensomebody at gmail.com (Warren Harris) Date: Wed Nov 19 18:27:24 2008 Subject: [Haskell-cafe] streaming translation using monads In-Reply-To: References: <38C9CD80-7FFB-43EB-9970-258A5ACEB8A0@gmail.com> Message-ID: <0ABB9A2E-A395-4804-A6B2-5BC1667A178D@gmail.com> On Nov 19, 2008, at 12:19 PM, Justin Bailey wrote: > On Wed, Nov 19, 2008 at 11:50 AM, Warren Harris > wrote: >> Now perhaps the in-memory list part was a bad conclusion since the >> queries >> can be decorated with translation functions capable of streaming >> the results >> out to another channel. However, the use of a universal type for >> the values >> would still seem to be required since there is no way to implement >> type-indexed values when the queries themselves are expressed as an >> abstract >> datatype rather than as functions. Am I overlooking something? >> > > If the type of the input determines the type of the output, and the > type of the input can be determined statically, then I think you are > overlooking this technique. But if your application requires that each > input expression be sent to the remote client before type information > can be determined, then you are right. > > In the case of HaskellDB, each operator/term in the Query monad > enriches the type information available. Of course, that enrichment > happens at compile time and occurs via type inference. For example, > assuming two tables T1 and T2, with columns T1col and T2col, this > expression: > > simpleQuery = do > t1 <- table T1 > t2 <- table T2 > restrict ( .. some expression ...) > project (t1 ! T1col1 # t2 ! T2col1) > > Gives a type similar to Query (RecCons T1Col1 Int (RecCons T2 Col2 Int > RecNil)). RecCons and RecNil are types that allow a list to be built > at the type level. The list carries the column names and types in the > resulting projection. The type information is used to ensure queries > only refer to columns that exist, datatypes are compared sensibly, > etc. If in your case you can build that kind of structure based purely > on the "input language" operators/terms, then it seems you could build > the entire "output expression" in one shot. But again, if input and > output have to be interleaved then I think you are stuck. What you describe is very similar to my current implementation, except I'm using a continuation function to receive the results input from the remote server rather than creating a list. The continuation's type (a curried function) is analogous to a list at the type level, if I understand correctly. However, since what I would like to do is stream the results in from one server and out to another (translating as I go), I really need some way to hook my translation in between each primitive field read from the input. So inside the body of the 'project' call you've given above, I might like to say something like: v1 <- t1 ! T1col1; v2 <- t2 ! T2col1; send client (trans v1 v2); return () However, since this input-receiving expression is now expressed as monad, it doesn't seem possible to use it to simultaneously formulate the output expressions that must be sent to the remote server to cause T1col1 and T2col1 to be requested. In my particular application, the remote server not only handles simple directives to retrieve sequences of primitives like T1col1, T2col1, but also higher-order formulations of them as lists and tuples. So the server may be sent a request like "(T1col1, (list (T2col1, T2col2)))" meaning "request the tuple of T1col1 followed by a (possibly long) sequence of T2col1, T2col2 pairs" and I want to be able to translate the incoming result stream without holding the entire thing in memory. Obviously I can do this by having one operation to generate the outbound query from a target language expression (implemented with an algebraic datatype), and another operation to handle the results based on the same expression, but it seems like some sort of formulation should be possible that allows both operations to be expressed simultaneously. In fact, I get that with the continuation-oriented combinators I mentioned earlier, but in practice I've found them to be very hard to work with. Just to make it more concrete, the above example might be expressed with my continuation-based combinators as: T1col1 ==> (\ k t1 -> send client (trans1 t1); k) ++ list (T2col1 ++ T2col2 ==> (\ k t2c1 t2c2 -> send client (trans2 t2c1 t2c2); k))) + + ... Here, the first function receives the value read from T1col1, translates it and send it to the originator of the request. This function is substituted for the an overall continuation -- receives the overall continuation as its first argument, k, and returns it at the end without passing any values to it. This effectively consumes the value t1. The second function is similar, and is called for each pair received from the list. The combinator '++', primitive directives like T1col1, and higher-order directives like 'list' are responsible for dealing with the overall expression grammar (i/o of delimiters, etc) and folding the overall continuation through the results as they are received. Sorry for being so long-winded here... I really appreciate your input. Warren From conal at conal.net Wed Nov 19 21:07:34 2008 From: conal at conal.net (Conal Elliott) Date: Wed Nov 19 21:01:40 2008 Subject: [Haskell-cafe] portable arrow instances In-Reply-To: <200811181501.00542.g9ks157k@acme.softbase.org> References: <200811181501.00542.g9ks157k@acme.softbase.org> Message-ID: Hi Wolfgang, I use CPP to manage such differences between 6.8, 6.9, and 6.10. As an example, see http://hackage.haskell.org/packages/archive/TypeCompose/latest/doc/html/src/Control-Compose.html. Regards, - Conal On Tue, Nov 18, 2008 at 6:01 AM, Wolfgang Jeltsch < g9ks157k@acme.softbase.org> wrote: > Hello, > > how do I make a library work with both GHC 6.8 and GHC 6.10? According to > , I > should change all my Arrow instances but then they don't work with GHC 6.8 > anymore, do they? Or is the solution to force GHC 6.8 users to use > base-4.0.0.0? > > 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/20081119/25df0e8c/attachment.htm From john at repetae.net Wed Nov 19 23:25:21 2008 From: john at repetae.net (John Meacham) Date: Wed Nov 19 23:19:25 2008 Subject: [Haskell-cafe] Hackage policy question In-Reply-To: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com> References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com> Message-ID: <20081120042521.GK350@sliver.repetae.net> The usual solution to this is the 'release version', which is used in most (all?) other packaging systems. namely, you have foo-1.2-4, where 4 is the release version which documents what version the meta-info is. For instance, when bugs are fixed in the rpm spec file or deb package that number is bumped and it is independent of the underlying packaged softwares release. It would be very useful if hackage could support something like this. John -- John Meacham - ?repetae.net?john? From DekuDekuplex at Yahoo.com Wed Nov 19 23:26:47 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Wed Nov 19 23:21:08 2008 Subject: [Haskell-cafe] (OT) Has GHC stopped being the "Glorious" Glasgow Haskell Compiler? Message-ID: <1jp9i4d5odpbi1emafc4abmk1h1ni3ut3f@4ax.com> IIRC, until very recently, the home page for GHC (see http://www.haskell.org/ghc/index.html) listed the compiler name as "The Glorious Glasgow Haskell Compiler." I wanted to write a blog entry using this aspect, but now the adjective "Glorious" seems to be missing. Am I missing something, or has the nickname been changed? -- Benjamin L. Russell http://dekudekuplex.wordpress.com/ From dons at galois.com Wed Nov 19 23:29:22 2008 From: dons at galois.com (Don Stewart) Date: Wed Nov 19 23:23:23 2008 Subject: [Haskell-cafe] (OT) Has GHC stopped being the "Glorious" Glasgow Haskell Compiler? In-Reply-To: <1jp9i4d5odpbi1emafc4abmk1h1ni3ut3f@4ax.com> References: <1jp9i4d5odpbi1emafc4abmk1h1ni3ut3f@4ax.com> Message-ID: <20081120042922.GE8627@scytale.galois.com> It was and remains truly Glorious. -- Don DekuDekuplex: > IIRC, until very recently, the home page for GHC (see > http://www.haskell.org/ghc/index.html) listed the compiler name as > "The Glorious Glasgow Haskell Compiler." > > I wanted to write a blog entry using this aspect, but now the > adjective "Glorious" seems to be missing. > > Am I missing something, or has the nickname been changed? > > -- Benjamin L. Russell > http://dekudekuplex.wordpress.com/ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From dons at galois.com Thu Nov 20 00:43:21 2008 From: dons at galois.com (Don Stewart) Date: Thu Nov 20 00:37:59 2008 Subject: [Haskell-cafe] portable arrow instances In-Reply-To: References: <200811181501.00542.g9ks157k@acme.softbase.org> Message-ID: <20081120054321.GJ8627@scytale.galois.com> Could you add this info/link to the upgrading page? http://www.haskell.org/haskellwiki/Upgrading_packages#Arrow_instances>, Using social/community processes to parallelise the job of finding all the upgrade routes -- I like it :-) -- Don conal: > Hi Wolfgang, > > I use CPP to manage such differences between 6.8, 6.9, and 6.10. As an > example, see > [1]http://hackage.haskell.org/packages/archive/TypeCompose/latest/doc/html/src/Control-Compose.html > . > > Regards, - Conal > > On Tue, Nov 18, 2008 at 6:01 AM, Wolfgang Jeltsch > <[2]g9ks157k@acme.softbase.org> wrote: > > Hello, > > how do I make a library work with both GHC 6.8 and GHC 6.10? According > to > <[3]http://www.haskell.org/haskellwiki/Upgrading_packages#Arrow_instances>, > I > should change all my Arrow instances but then they don't work with GHC > 6.8 > anymore, do they? Or is the solution to force GHC 6.8 users to use > base-4.0.0.0? > > Best wishes, > Wolfgang > _______________________________________________ > Haskell-Cafe mailing list > [4]Haskell-Cafe@haskell.org > [5]http://www.haskell.org/mailman/listinfo/haskell-cafe > > References > > Visible links > 1. http://hackage.haskell.org/packages/archive/TypeCompose/latest/doc/html/src/Control-Compose.html > 2. mailto:g9ks157k@acme.softbase.org > 3. http://www.haskell.org/haskellwiki/Upgrading_packages#Arrow_instances > 4. mailto:Haskell-Cafe@haskell.org > 5. 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 mad.one at gmail.com Thu Nov 20 01:15:06 2008 From: mad.one at gmail.com (Austin Seipp) Date: Thu Nov 20 01:09:11 2008 Subject: [Haskell-cafe] Hackage policy question In-Reply-To: <20081120042521.GK350@sliver.repetae.net> References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com> <20081120042521.GK350@sliver.repetae.net> Message-ID: <1227161016-sup-6333@existential.local> > The usual solution to this is the 'release version', which is used in > most (all?) other packaging systems. namely, you have foo-1.2-4, where 4 is the > release version which documents what version the meta-info is. For > instance, when bugs are fixed in the rpm spec file or deb package that > number is bumped and it is independent of the underlying packaged > softwares release. It would be very useful if hackage could support > something like this. > > John > Hi John, Hackage currently does not support this policy because of e.g. dependency tracking - previously hackage *was* allowed to upload packages of the form 'foo-1.2.3-unstable' but the problem was that it includes the -unstable as part of the version number. In the general case - arbitrary identifier suffixes as part of the version - when someone just specifies a dependency on 'foo', does foo-1.0-bar > foo-1.0-baz or not? Duncan 'fixed' hackage and put the restriction on the upload form - at the time I discussed this with him due to a problem with hsgnutls because it had the -barracuda suffix on the package version. In the case of meta-info specifying doc versions, I think we could allow package names of the form 'x.y.z_n' where x y z and n can only be integers. Then statements of the form e.g. 'foo-2.0_4 > foo-2.0_3' make sense and cabal and cabal install can understand this - of course, ghc-pkg won't accept such a version identifier, so it will only have meaning to cabal but in the case of documentation fixes and the like that's not much of a big deal really. Austin From dons at galois.com Thu Nov 20 02:24:36 2008 From: dons at galois.com (Don Stewart) Date: Thu Nov 20 02:18:37 2008 Subject: [Haskell-cafe] Haskell Reddit Message-ID: <20081120072436.GK8627@scytale.galois.com> I'm not sure if the cafe@ knows this, but there's a bit of a Haskell community (1200+ subscribers) built up around the Haskell subreddit on reddit.com, http://www.reddit.com/r/haskell/ A good source for news other than what appears on Planet Haskell. -- Don P.S. Feel free to submit things you like, so I don't have to :-) From p3k at iki.fi Thu Nov 20 03:58:04 2008 From: p3k at iki.fi (Pekka Karjalainen) Date: Thu Nov 20 03:52:08 2008 Subject: [Haskell-cafe] (OT) Has GHC stopped being the "Glorious" Glasgow Haskell Compiler? In-Reply-To: <1jp9i4d5odpbi1emafc4abmk1h1ni3ut3f@4ax.com> References: <1jp9i4d5odpbi1emafc4abmk1h1ni3ut3f@4ax.com> Message-ID: <233457100811200058h715e87f1o537ac10d12779e95@mail.gmail.com> On Thu, Nov 20, 2008 at 6:26 AM, Benjamin L.Russell wrote: > Am I missing something, or has the nickname been changed? Well, 'ghc --version' tells me that I am using "The Glorious Glasgow Haskell Compilation System, version 6.10.1"... From lionel at gamr7.com Thu Nov 20 04:02:43 2008 From: lionel at gamr7.com (Lionel Barret De Nazaris) Date: Thu Nov 20 03:54:55 2008 Subject: [Haskell-cafe] Haskell Reddit In-Reply-To: <20081120072436.GK8627@scytale.galois.com> References: <20081120072436.GK8627@scytale.galois.com> Message-ID: <492527B3.5050008@gamr7.com> AFAIK, there are two public on this haskell reddit : haskeller and curious about haskelle (evolving pythonneers ?). So anything goes. (Don : you post a lot. Is that part of your morning routine ?) L. Don Stewart wrote: > I'm not sure if the cafe@ knows this, but there's a bit of a Haskell > community (1200+ subscribers) built up around the Haskell subreddit on > reddit.com, > > http://www.reddit.com/r/haskell/ > > A good source for news other than what appears on Planet Haskell. > > -- Don > > P.S. Feel free to submit things you like, so I don't have to :-) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Best Regards, lionel Barret de Nazaris, Gamr7 Founder & CTO ========================= Gamr7 : Cities for Games http://www.gamr7.com From duncan.coutts at worc.ox.ac.uk Thu Nov 20 05:52:38 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 20 05:46:46 2008 Subject: [Haskell-cafe] Hackage policy question In-Reply-To: <20081120042521.GK350@sliver.repetae.net> References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com> <20081120042521.GK350@sliver.repetae.net> Message-ID: <1227178358.7124.13.camel@localhost> On Wed, 2008-11-19 at 20:25 -0800, John Meacham wrote: > The usual solution to this is the 'release version', which is used in > most (all?) other packaging systems. namely, you have foo-1.2-4, where 4 is the > release version which documents what version the meta-info is. For > instance, when bugs are fixed in the rpm spec file or deb package that > number is bumped and it is independent of the underlying packaged > softwares release. It would be very useful if hackage could support > something like this. There are two solutions to this, one is to say it's just a convention, eg using 1.2.4 when you give it your meaning of 1.2_4. The reason deb, rpm etc need to distinguish the extra version is precisely because they do not control the upstream version number. Of course in the case of package authors uploading packages to hackage that is not the case. It's an upstream packaging format, not a downstream one. However when we want to manage a collection of packages on hackage then it is a bit more like a downstream distro and in that case there is a stronger argument for making tweaks to meta-data (without uploading new tarballs) and recording those revision numbers. Eg relaxing or tightening versions of constraints as new information becomes available. One possibility there is to keep a version of the .cabal file outside of the tarball in the hackage index and record a x-hackage-revision: 3 field in that. It'd be incremented each time someone (author/maintainer or packager collection herder) makes a tweak. Duncan From duncan.coutts at worc.ox.ac.uk Thu Nov 20 05:54:38 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 20 05:48:45 2008 Subject: [Haskell-cafe] GHC 6.10.1 and cabal[-install] In-Reply-To: <200811201041.59293.dm.maillists@gmail.com> References: <200811181101.14630.g9ks157k@acme.softbase.org> <1227083256.21705.46.camel@dell.linuxdev.us.dell.com> <200811201041.59293.dm.maillists@gmail.com> Message-ID: <1227178478.7124.16.camel@localhost> On Thu, 2008-11-20 at 10:41 +1300, Daniel McAllansmith wrote: > On Wed, 19 Nov 2008 21:27:36 Duncan Coutts wrote: > > It's even easier than that! Someone has done it already :-) > > > > http://hackage.haskell.org/trac/hackage/ticket/261 > > > > Thu Aug 28 16:55:16 CEST 2008 Chry Cheng > > * Marking packages deprecated > > Fixes ticket no. 261 as discussed in its annotations. Packages with > > "deprecated" "true" are excluded from the package list. Packages with > > "superseded by" tags provide links to their superseding packages in the > > package page. > > Does "excluded from the package list" mean that deprecated packages won't show > up on http://hackage.haskell.org/packages/archive/pkg-list.html ? As I understand it, yes. > If so, how does one go about finding and downloading deprecated packages? > Rely on the search function to find the package page? > How do you get a comprehensive list of the deprecated packages that have > existed? At the moment I think it would not be easy. You'd have to compare the current index with the upload log to find the hidden pages. > Perhaps there should be a deprecated-pkg-list.html page. > If being superseded implies deprecation this page is also where the superseded > packages would go, with appropriate supersedes/superseded-by links between > them. Sounds sensible. Duncan From duncan.coutts at worc.ox.ac.uk Thu Nov 20 06:03:12 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 20 05:57:20 2008 Subject: [Haskell-cafe] GHC 6.10.1 and cabal[-install] In-Reply-To: <200811191028.35559.g9ks157k@acme.softbase.org> References: <200811181101.14630.g9ks157k@acme.softbase.org> <200811181423.12306.g9ks157k@acme.softbase.org> <1227043498.21705.36.camel@dell.linuxdev.us.dell.com> <200811191028.35559.g9ks157k@acme.softbase.org> Message-ID: <1227178992.7124.24.camel@localhost> On Wed, 2008-11-19 at 10:28 +0100, Wolfgang Jeltsch wrote: > Am Dienstag, 18. November 2008 22:24 schrieben Sie: > > > > How do I install and configure it so that it is integrated best with > > > > GHC 6.10.1? For example, should cabal use some directory in the GHC > > > > tree to place compiled packages in? > > > > The defaults for user or global should be fine. There is no need to put > > additional packages into the ghc install tree, indeed I would recommend > > against doing that. > > Hmm, /usr/local is not so fine for me since it makes packages hard(er) to > uninstall. I use stow (). No problem. It's only a default, the same default as ./configure systems use. Like ./configure it accepts all the usual --prefix= --libdir= --bindir etc flags, again with more-or-less the same relationships between them. It's documented in the Cabal user guide. > > > Cabal wants to place package info in $HOME/.cabal. However, I want to > > > install packages globally with sudo. So I want to have a global package > > > cache. Is there a common directory to be used for that or is > > > cabal[-install] only for per-user installations? > > > > It can do per-user or global. Per-user is the default. > > > > If you want to do the build as user and just the install as root then > > you can use the --global --root-cmd=sudo options. If you want to use > > this every time then you can set that in the ~/.cabal/config file. > > I want the package cache etc. global. The problem is that with sudo, cabal > still uses $HOME/.cabal where $HOME is the home directory of the ordinary > user (not the one of root). If you want the package cache to be global then run it as root. Or edit your ~/.cabal/config to use a global shared dir for the package cache dir. > Does --global change the directory for cabal configuration and the package > cache to something different than $HOME/.cabal? No. But the ~/.cabal/config does specify the location of the package cache so you can make that a global dir. Perhaps I should ask what you're really trying to do, to see if there's some way we could support your use-case better. Do you have multiple users and you want to save disk space by sharing the package download cache? Perhaps we could put some recipe on how to integrate with stow on the Cabal wiki page. > > The cabal user guide lists the default install directories for global > > and user installs. > > Okay, I looked at the cabal-install docs. And the only doc seems to be the > output of cabal with the --help option. Pretty much all the stuff in the Cabal user guide applies to the cabal command line tool. There is some extra stuff in the cabal command line tool that is not yet adequately documented (ie only in --help). Duncan From duncan.coutts at worc.ox.ac.uk Thu Nov 20 06:12:07 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 20 06:06:14 2008 Subject: [Haskell-cafe] Cabal and more than one version In-Reply-To: <42784f260811190215j74050250t29022b272e2d67f5@mail.gmail.com> References: <42784f260811180148v7c48ed46p18132f44a377f8bf@mail.gmail.com> <1227043805.21705.42.camel@dell.linuxdev.us.dell.com> <42784f260811181653o7a8c1d35ydde860bf95f7b70a@mail.gmail.com> <1227085441.21705.51.camel@dell.linuxdev.us.dell.com> <42784f260811190215j74050250t29022b272e2d67f5@mail.gmail.com> Message-ID: <1227179527.7124.34.camel@localhost> On Wed, 2008-11-19 at 02:15 -0800, Jason Dusek wrote: > Duncan Coutts wrote: > > Jason Dusek wrote: > > > In the ticket, someone says: > > > > > > True though I suspect it looks a bit weird to the > > > uninitiated. We know to read the conditional syntax as an > > > implication constraint which can be applied in either > > > direction but I suspect many people read it in a directed > > > functional way. > > > > > > Does that mean you don't have to actually set 'splitBase' > > > explicitly? > > > > No, that is the point. You do not have to. The choice for the > > flag is completely determined automatically by the version of > > the base package that is chosen. > > When you say "chosen" is that the same as "detected"? No. Each package can only be built against a single version of a dependent package. So chosen really means chosen. It is the single version of the dependent package that we end up building your package against. > With 6.10, both versions of base are available -- what happens > then? The environment chooses the latest one? Good example. So in that case the system (with optional input from the user / package manager) has to choose one of them. Often there will be a constraint from the package so that there will be no real choice. When the choice is not constrained then it is more complicated: * 'rughc Setup configure' and 'cabal configure' use a simple (and occasionally wrong) heuristic to pick the latest version. * 'cabal install' uses a simple constraint solver and some global and local preferences to make the choice. At the moment the global preference is to pick base 3, because many many packages say "build-depends: base >= 3" but in fact fail when built with base-4. So the preference is a kind of patch to keep them building. Duncan From duncan.coutts at worc.ox.ac.uk Thu Nov 20 06:17:47 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 20 06:11:54 2008 Subject: [Haskell-cafe] GHC 6.10.1 and cabal[-install] In-Reply-To: <1227178992.7124.24.camel@localhost> References: <200811181101.14630.g9ks157k@acme.softbase.org> <200811181423.12306.g9ks157k@acme.softbase.org> <1227043498.21705.36.camel@dell.linuxdev.us.dell.com> <200811191028.35559.g9ks157k@acme.softbase.org> <1227178992.7124.24.camel@localhost> Message-ID: <1227179867.7124.40.camel@localhost> On Thu, 2008-11-20 at 11:03 +0000, Duncan Coutts wrote: > On Wed, 2008-11-19 at 10:28 +0100, Wolfgang Jeltsch wrote: > > > The cabal user guide lists the default install directories for global > > > and user installs. > > > > Okay, I looked at the cabal-install docs. And the only doc seems to be the > > output of cabal with the --help option. > > Pretty much all the stuff in the Cabal user guide applies to the cabal > command line tool. There is some extra stuff in the cabal command line > tool that is not yet adequately documented (ie only in --help). By the way I should note that we would very much appreciate anyone who wants to help us improve the documentation. There is some documentation around (the user guide is quite extensive) but it does not seem to be well organised or easy to find. Similarly there are several sources that are not really intended for end-users (like the cabal-install page on the dev wiki) that are top hits on google. So clearly we need to do a better job with organising. With cabal-install we've been moving from a phase where it was under heavy development and only just usable to the point where it's nearly the tool of choice in its niche, so documentation and ease of installation, error messages are now more important than they were previously. We could really do with some help on these things as the number of people actually spending time hacking on these projects is quite small given the number of users and their (justified) demands for better docs, better defaults, ease of use, etc. Duncan From john at repetae.net Thu Nov 20 07:06:46 2008 From: john at repetae.net (John Meacham) Date: Thu Nov 20 07:00:48 2008 Subject: [Haskell-cafe] Hackage policy question In-Reply-To: <1227178358.7124.13.camel@localhost> References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com> <20081120042521.GK350@sliver.repetae.net> <1227178358.7124.13.camel@localhost> Message-ID: <20081120120646.GN350@sliver.repetae.net> Well, my main concern is that I have projects that have several distribution formats, tarball, rpm, deb, and hopefully hackage (alongside the others as equals). I don't want the version numbers to get out of sync though, just because I have to reroll the hackage, or rpm, or whatever release, I don't want to have to artificially increase its version number such that it gets out of sync with the actual version number of the package. For instance, I have a yum repository that contains my various projects (DrIFT, jhc, etc..) and bumping the release version is what I need to do to get 'yum update' to grab new versions, but I don't want to have to rerelease hackage, tarball, or deb versions to keep my version numbers in sync just for fixing an rpm or distribution compatability issue. With rpm I don't have to do this since it has a release version, so I am looking for something similar on the hackage side of things. John -- John Meacham - ?repetae.net?john? From duncan.coutts at worc.ox.ac.uk Thu Nov 20 07:56:31 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 20 07:50:51 2008 Subject: [Haskell-cafe] Hackage policy question In-Reply-To: <20081120120646.GN350@sliver.repetae.net> References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com> <20081120042521.GK350@sliver.repetae.net> <1227178358.7124.13.camel@localhost> <20081120120646.GN350@sliver.repetae.net> Message-ID: <1227185791.7124.89.camel@localhost> On Thu, 2008-11-20 at 04:06 -0800, John Meacham wrote: > Well, my main concern is that I have projects that have several > distribution formats, tarball, rpm, deb, and hopefully hackage > (alongside the others as equals). I don't want the version numbers to > get out of sync though, just because I have to reroll the hackage, or > rpm, or whatever release, I don't want to have to artificially increase > its version number such that it gets out of sync with the actual version > number of the package. For instance, I have a yum repository that > contains my various projects (DrIFT, jhc, etc..) and bumping the release > version is what I need to do to get 'yum update' to grab new versions, > but I don't want to have to rerelease hackage, tarball, or deb versions > to keep my version numbers in sync just for fixing an rpm or > distribution compatability issue. With rpm I don't have to do this since > it has a release version, so I am looking for something similar on the > hackage side of things. If it's purely a change in the .cabal file then the second mechanism that I described should be ok. Or release foo-x.y.z.1 only on hackage with the semantics being that it's a minor build fix for the primary version number foo-x.y.z. The only difference is that someone can install both variants simultaneously. Duncan From john at repetae.net Thu Nov 20 08:56:36 2008 From: john at repetae.net (John Meacham) Date: Thu Nov 20 08:50:37 2008 Subject: [Haskell-cafe] Hackage policy question In-Reply-To: <1227185791.7124.89.camel@localhost> References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com> <20081120042521.GK350@sliver.repetae.net> <1227178358.7124.13.camel@localhost> <20081120120646.GN350@sliver.repetae.net> <1227185791.7124.89.camel@localhost> Message-ID: <20081120135636.GO350@sliver.repetae.net> On Thu, Nov 20, 2008 at 12:56:31PM +0000, Duncan Coutts wrote: > On Thu, 2008-11-20 at 04:06 -0800, John Meacham wrote: > > Well, my main concern is that I have projects that have several > > distribution formats, tarball, rpm, deb, and hopefully hackage > > (alongside the others as equals). I don't want the version numbers to > > get out of sync though, just because I have to reroll the hackage, or > > rpm, or whatever release, I don't want to have to artificially increase > > its version number such that it gets out of sync with the actual version > > number of the package. For instance, I have a yum repository that > > contains my various projects (DrIFT, jhc, etc..) and bumping the release > > version is what I need to do to get 'yum update' to grab new versions, > > but I don't want to have to rerelease hackage, tarball, or deb versions > > to keep my version numbers in sync just for fixing an rpm or > > distribution compatability issue. With rpm I don't have to do this since > > it has a release version, so I am looking for something similar on the > > hackage side of things. > > If it's purely a change in the .cabal file then the second mechanism > that I described should be ok. > > Or release foo-x.y.z.1 only on hackage with the semantics being that > it's a minor build fix for the primary version number foo-x.y.z. The > only difference is that someone can install both variants > simultaneously. yeah, but then we have the odd case of things like frisby 0.9.0 and 0.9.0.1 both floating about, where the second is actually just the cabalized version of the first, and not an actual version. it gets even more complicated if I actually want to create a _real_ frisby 0.9.0.1 for a bug fix in the code. A dedicated 'release' number would be ideal and would make things more in line with the other packaging formats. John -- John Meacham - ?repetae.net?john? From mdmkolbe at gmail.com Thu Nov 20 09:06:16 2008 From: mdmkolbe at gmail.com (Michael D. Adams) Date: Thu Nov 20 09:01:49 2008 Subject: [Haskell-cafe] Re: Begginer question about alignment in Storable In-Reply-To: References: Message-ID: On Wed, Nov 19, 2008 at 1:01 PM, Mauricio wrote: >> If you are using hsc2hs (if you are using Cabal this is easy; just >> rename the file to *.hsc and Cabal will take care of the rest), then >> there is a macro for making this easier and so you don't have to think >> about it. (...) > > Well, after reading FFI addendum, I'm using > my loyal text editor. Am I supposed to use > something else? Is there something a tool like > hsc2hs or cabal setup can do that is more > portable than what I could write myself? Where > should I learn about that? Not necessarily more portable but definitely easier to maintain. The GHC manual contains [1] some sparse info on how to use hsc2hs (it seems to be built in to GHC). But the major advantage of hsc2hs is that if your C struct changes or you use a different C compiler, the allignment and size as well as the offsets used in peek and poke will still be correct since the compiler will calculate it for you. (Of course hsc2hs can't help you if fields are added or removed from the struct.) So for example suppose you had a struct like: typedef struct { int a; char b; double c; } my_struct; And you wanted to write a storable instance. With hsc2hs you would write it like this: instance Storable Struct where alignment _ = #{alignment my_struct} sizeOf _ = #{size my_struct} peek ptr = do a <- #{peek my_struct, a} ptr b <- #{peek my_struct, b} ptr c <- #{peek my_struct, c} ptr return (MyStruct a, b, c) poke ptr (MyStruct a b c) = do #{poke my_struct, a} ptr a #{poke my_struct, b} ptr b #{poke my_struct, c} ptr c Note that I didn't have to worry myself about what padding the compiler might put between for example "a" and "b" or what size "int" is. When I wrote the hpapi [2] package using hsc2hs was a life saver for these sorts of things. (You might look in those sources for examples.) Regarding "cabal setup", that is only really needed if you are intending to build a package to distribute to other people. But if you do want to distribute it (e.g. on the hackage repository) cabal is the way to go. I only mentioned it because if you are already using cabal then cabal automatically figures out that *.hsc files need to be sent through hsc2hs. (GHC may also do this, I haven't tried.) What this means is that once you spend the time to set up a cabal file for your project, the extra work for you as a developer to enable using hsc2hs is almost nothing; you just have to rename the file. For project structures that cabel can understand natively (e.g. you just have a colection of Haskell, Alex, Happy, Hsc2hs, etc. files), I highly recommend using it. It is one of the simplest to use build system I've seen. (I don't have a good link for learning cabal; you'll have to google around (e.g. "haskell cabal") for info.) Michael D. Adams [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/hsc2hs.html [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hpapi From briqueabraque at yahoo.com Thu Nov 20 11:26:11 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Thu Nov 20 11:20:25 2008 Subject: [Haskell-cafe] Re: Begginer question about alignment in Storable In-Reply-To: References: Message-ID: > (...) But the major advantage of hsc2hs is that if your C > struct changes or you use a different C compiler, the allignment > and size as well as the offsets used in peek and poke will still > be correct since the compiler will calculate it for you. (...) > > And you wanted to write a storable instance. With hsc2hs you > would write it like this: (...) Thanks! This is actually a really nice tutorial! Do you mind if I try to find a place for it in the wiki? > Regarding "cabal setup", that is only really needed if you are > intending to build a package to distribute to other people. (...) I didn't know about hsc2hs, but I'm a big fan of cabal. I would use it even in "Hello Word". > (...) (I don't have a good link for learning cabal; you'll have > to google around (e.g. "haskell cabal") for info.) Compreensive as a reference, easy to follow as a tutorial: http://www.haskell.org/ghc/docs/latest/html/Cabal Best, Maur?cio From marlowsd at gmail.com Thu Nov 20 11:53:10 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 20 11:47:20 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: Haddock version 2.4.0 In-Reply-To: References: <200811061559.10325.g9ks157k@acme.softbase.org> Message-ID: <492595F6.7000308@gmail.com> David Waern wrote: > 2008/11/6 Wolfgang Jeltsch : >> Am Donnerstag, 6. November 2008 00:21 schrieb David Waern: >>> * Add framed view of the HTML documentation >> After many years with many people telling us that frames are bad, you add >> frame support to Haddock? Hmm. > > You should discuss this with Simon Marlow, as it was his idea. Thomas > Schilling implemented it. Personally, I think the frames are quite > handy, although not that pretty in their current form. More > importantly, you don't need to use them if you don't want to. Haddock > still generates the normal index.html as well as frames.html. It wasn't really my idea, it came from something Simon Michael did for darcs, although it doesn't seem to be working now: http://lists.osuosl.org/pipermail/darcs-users/2008-September/014084.html I mentioned it to Thomas, who implemented something similar for Haddock. I think the conclusion we came to was that frames are probably not the right way to go (surprise), but we'd still like a better layout for Haddock pages. It's looking a bit dated now, and you have to scroll through pages of useless synopsis to get to the real docs. Also the layout is internally horrible, using lots of fixed-size table cells - I played around with lots of different approaches to the layout at the time, but it had to work in IE6 which meant that most things didn't work. I'd really love it if someone could give Haddock a facelift. Cheers, Simon From dons at galois.com Thu Nov 20 13:22:38 2008 From: dons at galois.com (Don Stewart) Date: Thu Nov 20 13:16:41 2008 Subject: [Haskell-cafe] Haskell Reddit In-Reply-To: <492527B3.5050008@gamr7.com> References: <20081120072436.GK8627@scytale.galois.com> <492527B3.5050008@gamr7.com> Message-ID: <20081120182238.GC10478@scytale.galois.com> lionel: > AFAIK, there are two public on this haskell reddit : haskeller and > curious about haskelle (evolving pythonneers ?). Yes, I agree with that assessment. It is a way to interact with the "Haskell-curious". > So anything goes. > > (Don : you post a lot. Is that part of your morning routine ?) Indeed it is :-) -- Don From duncan.coutts at worc.ox.ac.uk Thu Nov 20 13:48:47 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 20 13:42:53 2008 Subject: [Haskell-cafe] Hackage policy question In-Reply-To: <20081120135636.GO350@sliver.repetae.net> References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com> <20081120042521.GK350@sliver.repetae.net> <1227178358.7124.13.camel@localhost> <20081120120646.GN350@sliver.repetae.net> <1227185791.7124.89.camel@localhost> <20081120135636.GO350@sliver.repetae.net> Message-ID: <1227206927.7124.111.camel@localhost> On Thu, 2008-11-20 at 05:56 -0800, John Meacham wrote: > On Thu, Nov 20, 2008 at 12:56:31PM +0000, Duncan Coutts wrote: > > On Thu, 2008-11-20 at 04:06 -0800, John Meacham wrote: > > > Well, my main concern is that I have projects that have several > > > distribution formats, tarball, rpm, deb, and hopefully hackage > > > (alongside the others as equals). I don't want the version numbers to > > > get out of sync though, just because I have to reroll the hackage, or > > > rpm, or whatever release, I don't want to have to artificially increase > > > its version number such that it gets out of sync with the actual version > > > number of the package. For instance, I have a yum repository that > > > contains my various projects (DrIFT, jhc, etc..) and bumping the release > > > version is what I need to do to get 'yum update' to grab new versions, > > > but I don't want to have to rerelease hackage, tarball, or deb versions > > > to keep my version numbers in sync just for fixing an rpm or > > > distribution compatability issue. With rpm I don't have to do this since > > > it has a release version, so I am looking for something similar on the > > > hackage side of things. > > > > If it's purely a change in the .cabal file then the second mechanism > > that I described should be ok. > > > > Or release foo-x.y.z.1 only on hackage with the semantics being that > > it's a minor build fix for the primary version number foo-x.y.z. The > > only difference is that someone can install both variants > > simultaneously. > > > yeah, but then we have the odd case of things like frisby 0.9.0 and > 0.9.0.1 both floating about, where the second is actually just the > cabalized version of the first, and not an actual version. it gets even > more complicated if I actually want to create a _real_ frisby 0.9.0.1 > for a bug fix in the code. A dedicated 'release' number would be ideal > and would make things more in line with the other packaging formats. What would it mean? Is frisby-0.9.0-r1 different from frisby-0.9.0? Can I install both at once? Is it just a tag on one digit of the version number or does it change the semantics? Can another package depend on frisby >= 0.9.0-r3 ? Duncan From jefferson.r.heard at gmail.com Thu Nov 20 14:18:08 2008 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Thu Nov 20 14:12:11 2008 Subject: [Haskell-cafe] Problem with GTK on OS X -- installed from source Message-ID: <4165d3a70811201118n6489d6ddqd8d4dcd448d7c1a9@mail.gmail.com> Building my app with gtk2hs, I get the following error when I try to compile a file that uses Template Haskell (I'm not using TH to do anythign with GTK, but it loads the package anyway) Loading package gtk-0.9.13 ... : can't load .so/.DLL for: gthread-2.0 (dlopen(libgthread-2.0.dylib, 10): image not found) From sdh33 at cornell.edu Thu Nov 20 14:25:25 2008 From: sdh33 at cornell.edu (Stephen Hicks) Date: Thu Nov 20 14:19:26 2008 Subject: [Haskell-cafe] Possible issue with Hoogle and Haddock? Message-ID: <50b5ae760811201125i15b723a9hbb972b67287f909b@mail.gmail.com> Hi, I was noticing recently that there seems to be a problem with Hoogle and Haddock. In particular, I just hoogled "bracket" and got the following result: bracket :: IO a -> a -> IO b -> a -> IO c -> IO c Clearly this is the wrong type, as it should be bracket :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c The Haddock-generated documentation at least has newlines to group the terms, but this is still far from correct. I noticed the same thing a while back in Parsec's documentation for token, token :: Stream s Identity t => t -> String -> t -> SourcePos -> t -> Maybe a -> Parsec s u a which again should have parens. Is this a bug? Is is something that's well-known? Cheers, steve From mdmkolbe at gmail.com Thu Nov 20 15:34:39 2008 From: mdmkolbe at gmail.com (Michael D. Adams) Date: Thu Nov 20 15:28:40 2008 Subject: [Haskell-cafe] Re: Begginer question about alignment in Storable In-Reply-To: References: Message-ID: On Thu, Nov 20, 2008 at 11:26 AM, Mauricio wrote: >> (...) But the major advantage of hsc2hs is that if your C >> struct changes or you use a different C compiler, the allignment >> and size as well as the offsets used in peek and poke will still >> be correct since the compiler will calculate it for you. (...) >> >> And you wanted to write a storable instance. With hsc2hs you >> would write it like this: (...) > > Thanks! This is actually a really nice tutorial! Do you mind if I > try to find a place for it in the wiki? Go right ahead(*). Of course if you put that in, you should note that the #{alignment foo} syntax is not currently built-in to hsc2hs. You have to add the following line to your haskell source file to add the alignment syntax: #let alignment t = "%lu", (unsigned long)offsetof(struct {char x__; t (y__); }, y__) For completeness I should note that if you had a string field (e.g. struct { char c_string_field[MAX_LEN]; }) you would have to do it a little different. For example in peek: peek ptr = do s <- peekCString $ #{ptr c_type,c_string_field} ptr return (Foo s) Then in poke you would do: poke ptr (Foo s) = do withCStringLen (take maxLen value) $ uncurry (copyArray $ #{ptr c_type,c_string_field} ptr) where maxLen = #{const MAX_LEN} Note the use of #{ptr} instead of #{peek} since we want the address of the c_string_field rather than it's value. Unfortunately for the "struct { char *c_string_field; }" style there is no good general solution because you have to worry about allocating memory to have c_string_field point to. I'll leave figuring out #{enum}, but it can also be quite helpful in translating C enums/defines into Haskell. Michael D. Adams (*) For the lawyers: I hereby place that and these code snippet in the public domain or the nearest legal equivalent for those countries that don't have a legal concept of public domain. From jefferson.r.heard at gmail.com Thu Nov 20 15:47:07 2008 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Thu Nov 20 15:41:09 2008 Subject: [Haskell-cafe] Re: Problem with GTK on OS X -- installed from source In-Reply-To: <4165d3a70811201118n6489d6ddqd8d4dcd448d7c1a9@mail.gmail.com> References: <4165d3a70811201118n6489d6ddqd8d4dcd448d7c1a9@mail.gmail.com> Message-ID: <4165d3a70811201247n2045ef51jfd6c2b44e5a098e9@mail.gmail.com> Here we go again. App finally linked, but then I get this error: jeff-heards-macbook:IlluminateGL jeff$ ./Illuminate dyld: lazy symbol binding failed: Symbol not found: _glXQueryExtension Referenced from: /opt/local/lib/libgdkglext-x11-1.0.0.dylib Expected in: flat namespace dyld: Symbol not found: _glXQueryExtension Referenced from: /opt/local/lib/libgdkglext-x11-1.0.0.dylib Expected in: flat namespace Trace/BPT trap I rebuilt gtk2hs to make sure, with --enable-opengl, and I stlll get the error. Any ideas? On Thu, Nov 20, 2008 at 2:18 PM, Jeff Heard wrote: > Building my app with gtk2hs, I get the following error when I try to > compile a file that uses Template Haskell (I'm not using TH to do > anythign with GTK, but it loads the package anyway) > > Loading package gtk-0.9.13 ... : can't load .so/.DLL > for: gthread-2.0 (dlopen(libgthread-2.0.dylib, 10): image not found) > From john at repetae.net Thu Nov 20 17:00:49 2008 From: john at repetae.net (John Meacham) Date: Thu Nov 20 16:54:50 2008 Subject: [Haskell-cafe] Hackage policy question In-Reply-To: <1227206927.7124.111.camel@localhost> References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com> <20081120042521.GK350@sliver.repetae.net> <1227178358.7124.13.camel@localhost> <20081120120646.GN350@sliver.repetae.net> <1227185791.7124.89.camel@localhost> <20081120135636.GO350@sliver.repetae.net> <1227206927.7124.111.camel@localhost> Message-ID: <20081120220049.GP350@sliver.repetae.net> On Thu, Nov 20, 2008 at 06:48:47PM +0000, Duncan Coutts wrote: > > yeah, but then we have the odd case of things like frisby 0.9.0 and > > 0.9.0.1 both floating about, where the second is actually just the > > cabalized version of the first, and not an actual version. it gets even > > more complicated if I actually want to create a _real_ frisby 0.9.0.1 > > for a bug fix in the code. A dedicated 'release' number would be ideal > > and would make things more in line with the other packaging formats. > > What would it mean? Is frisby-0.9.0-r1 different from frisby-0.9.0? Can > I install both at once? Is it just a tag on one digit of the version > number or does it change the semantics? Can another package depend on > frisby >= 0.9.0-r3 ? No, the idea of a release number is that it does not take place in dependency tracking. frisby-0.9.0 is the base package, independent of hackage,rpm, or any distro that defines the API and is what you depend on in code. the release specifies the current 'roll' or 'build', a specific set of options and commands to get it to build in a certain environment. frisby-0.9.0-r4 always superceeds and should replace frisby-0.9.0-r3, but as far as anything is concerned frisby-0.9.0 is all that is installed. Another motivating situation is that I generally don't maintain the cabalized (or debed for that matter) builds of my tools but they are done by third parties, so when they need to upload a fixed version to hackage, it would give them a place to bump up the release number without having to coordinate anything upstream. It says "this is a new hackaged version of the same project". John -- John Meacham - ?repetae.net?john? From igloo at earth.li Thu Nov 20 20:08:33 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Nov 20 20:02:35 2008 Subject: [Haskell-cafe] Possible issue with Hoogle and Haddock? In-Reply-To: <50b5ae760811201125i15b723a9hbb972b67287f909b@mail.gmail.com> References: <50b5ae760811201125i15b723a9hbb972b67287f909b@mail.gmail.com> Message-ID: <20081121010833.GA7508@matrix.chaos.earth.li> On Thu, Nov 20, 2008 at 02:25:25PM -0500, Stephen Hicks wrote: > > I was noticing recently that there seems to be a problem with Hoogle > and Haddock. In particular, I just hoogled "bracket" and got the > following result: > bracket :: IO a -> a -> IO b -> a -> IO c -> IO c > Clearly this is the wrong type, as it should be > bracket :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c > > Is this a bug? Is is something that's well-known? Yes, it's a known bug: http://hackage.haskell.org/trac/ghc/ticket/2584 Thanks Ian From conal at conal.net Fri Nov 21 02:14:51 2008 From: conal at conal.net (Conal Elliott) Date: Fri Nov 21 02:08:51 2008 Subject: [Haskell-cafe] portable arrow instances In-Reply-To: <20081120054321.GJ8627@scytale.galois.com> References: <200811181501.00542.g9ks157k@acme.softbase.org> <20081120054321.GJ8627@scytale.galois.com> Message-ID: Done! Thanks for the suggestion. - Conal On Wed, Nov 19, 2008 at 9:43 PM, Don Stewart wrote: > Could you add this info/link to the upgrading page? > > http://www.haskell.org/haskellwiki/Upgrading_packages#Arrow_instances>, > > Using social/community processes to parallelise the job of finding all > the upgrade routes -- I like it :-) > > -- Don > > > conal: > > Hi Wolfgang, > > > > I use CPP to manage such differences between 6.8, 6.9, and 6.10. As > an > > example, see > > [1] > http://hackage.haskell.org/packages/archive/TypeCompose/latest/doc/html/src/Control-Compose.html > > . > > > > Regards, - Conal > > > > On Tue, Nov 18, 2008 at 6:01 AM, Wolfgang Jeltsch > > <[2]g9ks157k@acme.softbase.org> wrote: > > > > Hello, > > > > how do I make a library work with both GHC 6.8 and GHC 6.10? > According > > to > > <[3] > http://www.haskell.org/haskellwiki/Upgrading_packages#Arrow_instances>, > > I > > should change all my Arrow instances but then they don't work with > GHC > > 6.8 > > anymore, do they? Or is the solution to force GHC 6.8 users to use > > base-4.0.0.0? > > > > Best wishes, > > Wolfgang > > _______________________________________________ > > Haskell-Cafe mailing list > > [4]Haskell-Cafe@haskell.org > > [5]http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > References > > > > Visible links > > 1. > http://hackage.haskell.org/packages/archive/TypeCompose/latest/doc/html/src/Control-Compose.html > > 2. mailto:g9ks157k@acme.softbase.org > > 3. > http://www.haskell.org/haskellwiki/Upgrading_packages#Arrow_instances > > 4. mailto:Haskell-Cafe@haskell.org > > 5. 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/20081120/3603cc59/attachment.htm From neil.mitchell.2 at credit-suisse.com Fri Nov 21 03:21:51 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Fri Nov 21 03:16:31 2008 Subject: [Haskell-cafe] Possible issue with Hoogle and Haddock? In-Reply-To: <20081121010833.GA7508@matrix.chaos.earth.li> References: <50b5ae760811201125i15b723a9hbb972b67287f909b@mail.gmail.com> <20081121010833.GA7508@matrix.chaos.earth.li> Message-ID: > > I was noticing recently that there seems to be a problem > with Hoogle > > and Haddock. In particular, I just hoogled "bracket" and got the > > following result: > > bracket :: IO a -> a -> IO b -> a -> IO c -> IO c > Clearly this is the > > wrong type, as it should be > > bracket :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c > > > > Is this a bug? Is is something that's well-known? > > Yes, it's a known bug: > http://hackage.haskell.org/trac/ghc/ticket/2584 I can make a work around for Hoogle (well, I can write a workaround in the Hoogle specific code of Haddock), but was hoping that the bug would be fixed before 6.10. I guess its now worth making the Hoogle specific fix. Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From hpacheco at gmail.com Fri Nov 21 05:22:36 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Fri Nov 21 05:16:37 2008 Subject: [Haskell-cafe] System Fc in GHC Message-ID: <7b92c2840811210222r5055af2cn4eb561ce5d849f9@mail.gmail.com> Since System Fc is implemented in the latest releases of GHC, is it implemented in Haskell so that I can play with the translator? Can I find it in the ghc sources? Thanks, hugo -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081121/bc1a5111/attachment.htm From simonpj at microsoft.com Fri Nov 21 05:35:03 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 21 05:29:06 2008 Subject: [Haskell-cafe] System Fc in GHC In-Reply-To: <7b92c2840811210222r5055af2cn4eb561ce5d849f9@mail.gmail.com> References: <7b92c2840811210222r5055af2cn4eb561ce5d849f9@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33192419B2B@EA-EXMSG-C334.europe.corp.microsoft.com> Yes, Fc is the intermediate language. The data type is in compiler/coreSyn/CoreSyn.lhs. The Commentary give a lot more context (albeit not Fc-specific). http://hackage.haskell.org/trac/ghc/wiki/Commentary Simon From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Hugo Pacheco Sent: 21 November 2008 10:23 To: Haskell Cafe Subject: [Haskell-cafe] System Fc in GHC Since System Fc is implemented in the latest releases of GHC, is it implemented in Haskell so that I can play with the translator? Can I find it in the ghc sources? Thanks, hugo -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081121/5059a6a5/attachment.htm From briqueabraque at yahoo.com Fri Nov 21 05:43:34 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Fri Nov 21 05:37:42 2008 Subject: [Haskell-cafe] Re: Begginer question about alignment in Storable In-Reply-To: References: Message-ID: >> Thanks! This is actually a really nice tutorial! Do you mind if I >> try to find a place for it in the wiki? > Go right ahead (...) For reference: http://haskell.org/haskellwiki/FFI_cook_book Best, Maur?cio From reiner.pope at gmail.com Fri Nov 21 07:59:48 2008 From: reiner.pope at gmail.com (Reiner Pope) Date: Fri Nov 21 07:53:48 2008 Subject: [Haskell-cafe] Fixity parsing, Template Haskell Message-ID: <4cf038ee0811210459j6d8238c6r73ca3a3932d902cc@mail.gmail.com> This post follows on from a discussion about a month ago, called "Haskell Syntax Inside Quasiquote". To summarise, suppose I want to create a Haskell quasiquoter for lists, eg [$list|1,x^2,y,3|] (representing the list [1,x^2,y,3]) Ideally, this would allow arbitrary Haskell expressions for each element of the list (provided, of course, that the types are correct). To write this list quasiquoter, I would need to parse Haskell expressions. This is doable[1], but is necessarily buggy when infix operators are concerned. For instance, a user of the list quasiquoter may define two new operators, (+*) and (+^), and then write [$list|1+*2+^3|] Being able to correctly parse such an expression depends on known the two operator's fixities, which is currently impossible. The problem is that potentially non-local fixity declarations affect parsing. As far as I can see, the correct solution is to change the Template Haskell AST representation of fixity expressions from > data Exp = ... > | InfixE (Maybe Exp) Exp (Maybe Exp) to something like > type Op = Exp --- because TH doesn't distinguish operators from expressions > data Exp = ... > | InfixE [Exp] [Op] --- length [Exp] == 1 + length [Op], always > | LeftSection Exp Op > | RightSection Op Exp Apart from splitting of the sections, the important difference is that the expressions are parsed as a list of expressions separated by operators. So, my example above would be parsed as something like InfixE [parseExp "1", parseExp "2", parseExp "3"] ["+*", "+^"] Then, when Template Haskell performs the splice, it could correctly resolve the fixities. Of course, this would require a change to Template Haskell, so a second-best solution would be to forbid unparenthesised expressions in my quasiquoter. Then, parsing can proceed correctly without knowing the fixities. This would be easiest to do if haskell-src-exts changed its AST in a similar way to described above for Template Haskell. Any thoughts? Cheers, Reiner Pope [1] For instance, see haskell-src-meta, which uses haskell-src-exts as a parser, and then converts the AST into a form that Template Haskell recognises. From jason.dusek at gmail.com Fri Nov 21 09:40:14 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Fri Nov 21 09:34:13 2008 Subject: [Haskell-cafe] varargs zip Message-ID: <42784f260811210640i5b06c70bqb57b37efaa94d0ef@mail.gmail.com> It came up on IRC last night that there is no "generic" zip in Haskell. I decided to write one as an example, but it only half works. When the argument lists are all definitely of one type, instance selection works as expected; however, with numeric types, for example, things don't work out. I'm not sure how to express the idea that the result tuple determines the arguments types, with either of functional dependencies or associated types. -- _jsn |...example...| http://github.com/jsnx/haskell-demos/tree/master/generic_zip%2FGenericZip.hs From lemming at henning-thielemann.de Fri Nov 21 10:33:55 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Nov 21 10:27:55 2008 Subject: [Haskell-cafe] varargs zip In-Reply-To: <42784f260811210640i5b06c70bqb57b37efaa94d0ef@mail.gmail.com> References: <42784f260811210640i5b06c70bqb57b37efaa94d0ef@mail.gmail.com> Message-ID: On Fri, 21 Nov 2008, Jason Dusek wrote: > It came up on IRC last night that there is no "generic" zip in > Haskell. I decided to write one as an example, but it only > half works. I think that the ZipList type for Applicative functors is a solution. http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html#t%3AZipList From jason.dusek at gmail.com Fri Nov 21 10:36:56 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Fri Nov 21 10:30:55 2008 Subject: [Haskell-cafe] varargs zip In-Reply-To: References: <42784f260811210640i5b06c70bqb57b37efaa94d0ef@mail.gmail.com> Message-ID: <42784f260811210736u4631b15dj4b3433f26ea4c709@mail.gmail.com> That would solve the problem that solving the problem would solve, but it does not solve the problem I asked about! -- _jsn From leather at cs.uu.nl Fri Nov 21 11:22:24 2008 From: leather at cs.uu.nl (Sean Leather) Date: Fri Nov 21 11:16:25 2008 Subject: [Haskell-cafe] varargs zip In-Reply-To: <42784f260811210640i5b06c70bqb57b37efaa94d0ef@mail.gmail.com> References: <42784f260811210640i5b06c70bqb57b37efaa94d0ef@mail.gmail.com> Message-ID: <3c6288ab0811210822l208217cgd7db9fe0d5cb6020@mail.gmail.com> > It came up on IRC last night that there is no "generic" zip in > Haskell. I decided to write one as an example, but it only > half works. > That depends on how you define "generic." ;) EMGM [1] has a generic zipWith [2]: > zipWith :: FRep3 ZipWith f => (a -> b -> c) -> f a -> f b -> Maybe (f c) This is generic according to the container type 'f'. A particular specialization of this is zip: > zip :: FRep3 ZipWith f => f a -> f b -> Maybe (f (a, b)) [1] http://www.cs.uu.nl/wiki/GenericProgramming/EMGM [2] http://hackage.haskell.org/packages/archive/emgm/0.1/doc/html/Generics-EMGM-Functions-ZipWith.html http://github.com/jsnx/haskell-demos/tree/master/generic_zip%2FGenericZip.hs >From looking at your code, it appears that you want a zip that is generic according to arity. You also don't seem to care about the container type, since you have only lists. So, the above isn't really related. Here's an adaptation of your code that works. Personally, I'd probably use Template Haskell. This is not really generic at all. Rather it's an advertisement for overloading. ;) > {-# LANGUAGE FlexibleInstances #-} > module GenericZip where > import Prelude hiding (zip) > import qualified Prelude (zip) > class Zip f where > zip :: f > instance Zip ([a] -> [a]) where > zip = id > instance Zip ([a] -> [b] -> [(a, b)]) where > zip = Prelude.zip > instance Zip ([a] -> [b] -> [c] -> [(a, b, c)]) where > zip as bs cs = zipWith (\a (b,c) -> (a,b,c)) as $ zip bs cs > instance Zip ([a] -> [b] -> [c] -> [d] -> [(a, b, c, d)]) where > zip as bs cs ds = zipWith (\a (b,c,d) -> (a,b,c,d)) as $ zip bs cs ds > example = zip [1,2::Int] ['a','b'] ["1","b"] :: [(Int,Char,String)] Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081121/f5570e20/attachment.htm From robgreayer at yahoo.com Fri Nov 21 12:31:24 2008 From: robgreayer at yahoo.com (Robert Greayer) Date: Fri Nov 21 12:27:29 2008 Subject: [Haskell-cafe] Hackage/Cabal/Haddock question Message-ID: <167098.8478.qm@web65706.mail.ac4.yahoo.com> How does Hackage run 'haddock' on uploaded packages? I had assumed it directly runs the cabal 'haddock' target, e.g. runhaskell Setup.hs haddock but it appears to perhaps be more complex than that. Some backrgound -- haddock doesn't seem to like quasiquotation - running haddock on a source tree that includes quasiquotations eventually results in: haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing (eliminating the code that contains [$xxx|....] constructs gets rid of the error.) so "runhaskell Setup.hs haddock" ends up not generating any documentation. I worked around this problem by using a 'UserHook' and adding in an extra path element to the source path prior to running haddock via Cabal: > main = defaultMainWithHooks (simpleUserHooks { > preHaddock = \_ _ -> return (Just $ emptyBuildInfo { hsSourceDirs = ["noqqsrc"]},[]) }) The additional directory contains an alternate version of modules that don't contain quasiquotation (just types and stubs), which seems to hide the versions that do. This works fine locally, but not on hackage (still get the same behavior in the build failure log). Of course, I'd prefer not to have to do this at all, so if anyone knows a way around the problem (or if its purely my problem -- I'm doing something wrong), I'd appreciate hearing about it. I'm using GHC 6.10.1, and have tried setup haddock with both the shipped-with-ghc version of haddock and the latest version. Thanks, rcg From jason.dusek at gmail.com Fri Nov 21 14:42:30 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Fri Nov 21 14:36:30 2008 Subject: [Haskell-cafe] varargs zip In-Reply-To: <3c6288ab0811210838l7317efe2n4caab413a64a39f9@mail.gmail.com> References: <42784f260811210640i5b06c70bqb57b37efaa94d0ef@mail.gmail.com> <3c6288ab0811210822l208217cgd7db9fe0d5cb6020@mail.gmail.com> <3c6288ab0811210838l7317efe2n4caab413a64a39f9@mail.gmail.com> Message-ID: <42784f260811211142x61e4cd04ref7dc628d550d097@mail.gmail.com> Sean Leather wrote: > > example = zip [1,2::Int] ['a','b'] ["1","b"] :: > > [(Int,Char,String)] > > BTW, I realized that this example also works in yours. You > weren't giving enough type annotations. Yes, exactly. Or in other words, the class definition does not correctly specify the dependencies. That is what I am writing in about -- I don't want clients to 'zip' to be required to put all those type annotations in. -- _jsn From dan.doel at gmail.com Fri Nov 21 17:23:17 2008 From: dan.doel at gmail.com (Dan Doel) Date: Fri Nov 21 17:17:21 2008 Subject: [Haskell-cafe] varargs zip In-Reply-To: <42784f260811210640i5b06c70bqb57b37efaa94d0ef@mail.gmail.com> References: <42784f260811210640i5b06c70bqb57b37efaa94d0ef@mail.gmail.com> Message-ID: <200811211723.18938.dan.doel@gmail.com> On Friday 21 November 2008 9:40:14 am Jason Dusek wrote: > It came up on IRC last night that there is no "generic" zip in > Haskell. I decided to write one as an example, but it only > half works. > > When the argument lists are all definitely of one type, > instance selection works as expected; however, with numeric > types, for example, things don't work out. I'm not sure how to > express the idea that the result tuple determines the > arguments types, with either of functional dependencies or > associated types. Here's some fancy type system stuff for your viewing pleasure: ---- snip ---- {-# LANGUAGE GADTs , TypeFamilies , EmptyDataDecls , TypeOperators , ScopedTypeVariables , FlexibleContexts #-} data Nil data a ::: b infixr ::: data Tuple ts where Nil :: Tuple Nil (:::) :: t -> Tuple ts -> Tuple (t ::: ts) type family Fun ts r :: * type instance Fun Nil r = r type instance Fun (t ::: ts) r = t -> Fun ts r type family Lists ts :: * type instance Lists Nil = Nil type instance Lists (t ::: ts) = [t] ::: Lists ts class Tup ts where uncurryT :: Fun ts r -> Tuple ts -> r curryT :: (Tuple ts -> r) -> Fun ts r zipT :: Tuple (Lists ts) -> [Tuple ts] instance Tup Nil where uncurryT r Nil = r curryT f = f Nil zipT Nil = repeat Nil instance Tup ts => Tup (t ::: ts) where uncurryT f (v ::: vs) = uncurryT (f v) vs curryT f = \v -> curryT (\t -> f (v ::: t)) zipT (l ::: ls) = zipWith (:::) l (zipT ls) zipWithT :: forall ts r. (Tup ts, Tup (Lists ts)) => ts -> Fun ts r -> Fun (Lists ts) [r] zipWithT witness f = cT (\t -> map (uT f) (zipT t)) where cT :: (Tuple (Lists ts) -> [r]) -> Fun (Lists ts) [r] cT = curryT uT :: Fun ts r -> Tuple ts -> r uT = uncurryT zwp :: forall a. Num a => [a] -> [a] -> [a] -> [a] zwp = zipWithT (undefined :: a ::: a ::: a ::: Nil) (\x y z -> x + y + z) zwf :: forall a b c d. (a -> b -> c -> d) -> [a] -> [b] -> [c] -> [d] zwf = zipWithT (undefined :: a ::: b ::: c ::: Nil) ---- snip ---- You'll need a GHC that's 6.10-ish for this to work. Cheers, -- Dan From reiner.pope at gmail.com Fri Nov 21 18:03:28 2008 From: reiner.pope at gmail.com (Reiner Pope) Date: Fri Nov 21 17:57:53 2008 Subject: [Haskell-cafe] Re: Fixity parsing, Template Haskell In-Reply-To: <4cf038ee0811210459j6d8238c6r73ca3a3932d902cc@mail.gmail.com> References: <4cf038ee0811210459j6d8238c6r73ca3a3932d902cc@mail.gmail.com> Message-ID: <4cf038ee0811211503p718e6eban38c5afa317a53645@mail.gmail.com> It occurs to me that changing the Template Haskell representation to a less-information representation is disadvantageous when code has been reified for examination by a Template Haskell-using library. In that case, the library would want maximum knowledge about the fixities. Perhaps the best solution is just to forbid unparenthesised infix expressions in the quasiquote language. Cheers, Reiner On Fri, Nov 21, 2008 at 11:59 PM, Reiner Pope wrote: > This post follows on from a discussion about a month ago, called > "Haskell Syntax Inside Quasiquote". > > To summarise, suppose I want to create a Haskell quasiquoter for lists, eg > [$list|1,x^2,y,3|] (representing the list [1,x^2,y,3]) > Ideally, this would allow arbitrary Haskell expressions for each > element of the list (provided, of course, that the types are correct). > > To write this list quasiquoter, I would need to parse Haskell > expressions. This is doable[1], but is necessarily buggy when infix > operators are concerned. For instance, a user of the list quasiquoter > may define two new operators, (+*) and (+^), and then write > [$list|1+*2+^3|] > Being able to correctly parse such an expression depends on known the > two operator's fixities, which is currently impossible. The problem is > that potentially non-local fixity declarations affect parsing. > > As far as I can see, the correct solution is to change the Template > Haskell AST representation of fixity expressions from >> data Exp = ... >> | InfixE (Maybe Exp) Exp (Maybe Exp) > to something like >> type Op = Exp --- because TH doesn't distinguish operators from expressions >> data Exp = ... >> | InfixE [Exp] [Op] --- length [Exp] == 1 + length [Op], always >> | LeftSection Exp Op >> | RightSection Op Exp > Apart from splitting of the sections, the important difference is that > the expressions are parsed as a list of expressions separated by > operators. So, my example above would be parsed as something like > > InfixE [parseExp "1", parseExp "2", parseExp "3"] ["+*", "+^"] > > Then, when Template Haskell performs the splice, it could correctly > resolve the fixities. > > Of course, this would require a change to Template Haskell, so a > second-best solution would be to forbid unparenthesised expressions in > my quasiquoter. Then, parsing can proceed correctly without knowing > the fixities. This would be easiest to do if haskell-src-exts changed > its AST in a similar way to described above for Template Haskell. > > Any thoughts? > > Cheers, > Reiner Pope > > [1] For instance, see haskell-src-meta, which uses haskell-src-exts as > a parser, and then converts the AST into a form that Template Haskell > recognises. > From kyagrd at gmail.com Fri Nov 21 19:12:06 2008 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Fri Nov 21 19:05:41 2008 Subject: [Haskell-cafe] Do I need an account to report build of Hacakge packages? Message-ID: I am just curious about how cabal report works. I recently figured out that there is a report command in cabal and it reports the reports generated by --build-reports option when building a package. Is this because I don't have an account on Hackage yet, or because of some other reasons? And if I make an account, where how I put that information in cabal config file? I've looked into the cabal config file and tried to change this myself before, but it wasn't very self explanatory to me. For instance, I tried to make the build-reports on by default, deleting haskell comment like double dashes "--" and put True flag after the colon, but keep getting parse error from cabal. I looked up the manual but it says that the config file is self explanatory, which isn't to me at all. Are there any documentations on this available anywhere? === error messages when I tried to report the build log === kyagrd@kyagrd:~$ cabal report Sending: POST http://hackage.haskell.org/buildreports HTTP/1.1 Content-Type: text/plain Content-Length: 281 Accept: text/plain Creating new connection to hackage.haskell.org Received: HTTP/1.1 404 Not Found Date: Fri, 21 Nov 2008 23:52:14 GMT Server: Apache/2.2.3 (Debian) Alternates: {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-2} {language cs} {length 745}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language de} {length 766}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language en} {length 611}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language es} {length 759}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language fr} {length 771}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language ga} {length 813}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language it} {length 692}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-2022-jp} {language ja} {length 749}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset euc-kr} {language ko} {length 703}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language nl} {length 688}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-2} {language pl} {length 707}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language pt-br} {length 753}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language ro} {length 689}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-5} {language sr} {length 716}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language sv} {length 722}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-9} {language tr} {length 755}} Vary: accept-language,accept-charset Content-Length: 418 Content-Type: text/html; charset=iso-8859-1 cabal: Unrecognised response from server. kyagrd@kyagrd:~$ cabal --version cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library From d at vidplace.com Fri Nov 21 19:19:37 2008 From: d at vidplace.com (David F. Place) Date: Fri Nov 21 19:12:35 2008 Subject: [Haskell-cafe] Extensible Exceptions Message-ID: <1227313177.3309.6.camel@Congo> Hi, All. I am trying to understand the new exceptions package in base-4 Control.Exceptions. The documentation for catchJust is the same as in Control.OldException including this example: result <- catchJust errorCalls thing_to_try handler Control.OldException provides the predicate errorCalls, but the new one does not. I don't see how to write it. Thanks for reading. Cheers, David From rmm-haskell at z.odi.ac Fri Nov 21 20:30:07 2008 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Fri Nov 21 20:24:13 2008 Subject: [Haskell-cafe] Extensible Exceptions In-Reply-To: <1227313177.3309.6.camel@Congo> References: <1227313177.3309.6.camel@Congo> Message-ID: <4927609F.5080104@z.odi.ac> I think catch is now basically what catchJust was -- you can just do > thing_to_try `catch` (\ (ErrorCall s) -> putStrLn s) and it will only catch ErrorCall exceptions. -Ross David F. Place wrote: > Hi, All. > > I am trying to understand the new exceptions package in base-4 > Control.Exceptions. The documentation for catchJust is the same as in > Control.OldException including this example: > > result <- catchJust errorCalls thing_to_try handler > > Control.OldException provides the predicate errorCalls, but the new one > does not. I don't see how to write it. > > Thanks for reading. > > Cheers, > David > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From kdamodar2000 at gmail.com Fri Nov 21 23:46:22 2008 From: kdamodar2000 at gmail.com (kk08) Date: Fri Nov 21 23:40:21 2008 Subject: [Haskell-cafe] Counting beta reductions for a Haskell program... Message-ID: <20623025.post@talk.nabble.com> Does GHC supports/has a command for counting total beta reductions taken by a program? Thanks. -- View this message in context: http://www.nabble.com/Counting-beta-reductions-for-a-Haskell-program...-tp20623025p20623025.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From ryani.spam at gmail.com Sat Nov 22 00:06:55 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sat Nov 22 00:00:52 2008 Subject: [Haskell-cafe] Counting beta reductions for a Haskell program... In-Reply-To: <20623025.post@talk.nabble.com> References: <20623025.post@talk.nabble.com> Message-ID: <2f9b2d30811212106x19a39443rbe9fa2eb54cf64d5@mail.gmail.com> This doesn't make a whole lot of sense. One of the reasons GHC-compiled code is so fast is that it turns into straight-line code whenever possible, via inlining, primitive optimizations, etc. I suppose there could be an option for the STG machine[1] to increment a counter on every "Enter", which loosely corresponds to a beta reduction, but the STG machine is only an island in the sea of compiled code GHC creates. - ryan [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.3729 On Fri, Nov 21, 2008 at 8:46 PM, kk08 wrote: > > Does GHC supports/has a command for counting total beta reductions taken by a > program? > > Thanks. > > -- > View this message in context: http://www.nabble.com/Counting-beta-reductions-for-a-Haskell-program...-tp20623025p20623025.html > Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From kdamodar2000 at gmail.com Sat Nov 22 00:22:15 2008 From: kdamodar2000 at gmail.com (kk08) Date: Sat Nov 22 00:16:11 2008 Subject: [Haskell-cafe] Counting beta reductions for a Haskell program... In-Reply-To: <2f9b2d30811212106x19a39443rbe9fa2eb54cf64d5@mail.gmail.com> References: <20623025.post@talk.nabble.com> <2f9b2d30811212106x19a39443rbe9fa2eb54cf64d5@mail.gmail.com> Message-ID: <20633639.post@talk.nabble.com> Thanks. I heard that a Gofer compiler (a Haskell dialect) supports counting the Beta reductions. Hence I thought GHC/Hugs would have a similar facility. Ryan Ingram wrote: > > This doesn't make a whole lot of sense. One of the reasons > GHC-compiled code is so fast is that it turns into straight-line code > whenever possible, via inlining, primitive optimizations, etc. > > > - ryan > > [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.3729 > > On Fri, Nov 21, 2008 at 8:46 PM, kk08 wrote: >> >> Does GHC supports/has a command for counting total beta reductions taken >> by a >> program? >> >> Thanks. >> >> -- >> View this message in context: >> http://www.nabble.com/Counting-beta-reductions-for-a-Haskell-program...-tp20623025p20623025.html >> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > 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/Counting-beta-reductions-for-a-Haskell-program...-tp20623025p20633639.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From aneumann at inf.fu-berlin.de Sat Nov 22 02:18:14 2008 From: aneumann at inf.fu-berlin.de (Adrian Neumann) Date: Sat Nov 22 02:12:35 2008 Subject: [Haskell-cafe] Counting beta reductions for a Haskell program... In-Reply-To: <20633639.post@talk.nabble.com> References: <20623025.post@talk.nabble.com> <2f9b2d30811212106x19a39443rbe9fa2eb54cf64d5@mail.gmail.com> <20633639.post@talk.nabble.com> Message-ID: <1051D90C-3AB2-47B5-A2E3-91DE3D8D61FC@inf.fu-berlin.de> Hugs has, afaik, a "output reduction count" option somewhere. At least it had one the last time I used it. - Adrian Am 22.11.2008 um 06:22 schrieb kk08: > > Thanks. > I heard that a Gofer compiler (a Haskell dialect) supports counting > the Beta > reductions. > Hence I thought GHC/Hugs would have a similar facility. > > > > Ryan Ingram wrote: >> >> This doesn't make a whole lot of sense. One of the reasons >> GHC-compiled code is so fast is that it turns into straight-line code >> whenever possible, via inlining, primitive optimizations, etc. >> >> >> - ryan >> >> [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.3729 >> >> On Fri, Nov 21, 2008 at 8:46 PM, kk08 wrote: >>> >>> Does GHC supports/has a command for counting total beta >>> reductions taken >>> by a >>> program? >>> >>> Thanks. >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Counting-beta-reductions-for-a-Haskell- >>> program...-tp20623025p20623025.html >>> Sent from the Haskell - Haskell-Cafe mailing list archive at >>> Nabble.com. >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> _______________________________________________ >> 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/Counting-beta- > reductions-for-a-Haskell-program...-tp20623025p20633639.html > Sent from the Haskell - Haskell-Cafe mailing list archive at > Nabble.com. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: Signierter Teil der Nachricht Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081122/f394c242/PGP.bin From kdamodar2000 at gmail.com Sat Nov 22 02:22:07 2008 From: kdamodar2000 at gmail.com (damodar kulkarni) Date: Sat Nov 22 02:16:05 2008 Subject: [Haskell-cafe] Counting beta reductions for a Haskell program... In-Reply-To: <1051D90C-3AB2-47B5-A2E3-91DE3D8D61FC@inf.fu-berlin.de> References: <20623025.post@talk.nabble.com> <2f9b2d30811212106x19a39443rbe9fa2eb54cf64d5@mail.gmail.com> <20633639.post@talk.nabble.com> <1051D90C-3AB2-47B5-A2E3-91DE3D8D61FC@inf.fu-berlin.de> Message-ID: Yes Hugs has a option "+s" but it counts some sort of reductions not exactly the beta reductions. Thanks. -Damodar 2008/11/22 Adrian Neumann > Hugs has, afaik, a "output reduction count" option somewhere. At least it > had one the last time I used it. > > - Adrian > > Am 22.11.2008 um 06:22 schrieb kk08: > > > >> Thanks. >> I heard that a Gofer compiler (a Haskell dialect) supports counting the >> Beta >> reductions. >> Hence I thought GHC/Hugs would have a similar facility. >> >> >> >> Ryan Ingram wrote: >> >>> >>> This doesn't make a whole lot of sense. One of the reasons >>> GHC-compiled code is so fast is that it turns into straight-line code >>> whenever possible, via inlining, primitive optimizations, etc. >>> >>> >>> - ryan >>> >>> [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.3729 >>> >>> On Fri, Nov 21, 2008 at 8:46 PM, kk08 wrote: >>> >>>> >>>> Does GHC supports/has a command for counting total beta reductions taken >>>> by a >>>> program? >>>> >>>> Thanks. >>>> >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/Counting-beta-reductions-for-a-Haskell- >>>> program...-tp20623025p20623025.html >>>> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe@haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>>> _______________________________________________ >>> 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/Counting-beta- >> reductions-for-a-Haskell-program...-tp20623025p20633639.html >> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- ---------------------------------------------------- Are you a woman reading this mail? If yes, please read the mail twice. Read why a woman is only half intelligent as that of a man? http://www.jeansasson.com/law_and_government.htm) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081122/89c4dcfb/attachment.htm From ods94065 at gmail.com Sat Nov 22 04:31:06 2008 From: ods94065 at gmail.com (Owen Smith) Date: Sat Nov 22 04:25:04 2008 Subject: [Haskell-cafe] Operator cheat sheet, and monadic style q Message-ID: Greetings, I'm a longtime Haskell-curious programmer who, after a few aborted attempts at getting started and long nights staring at academic papers, finally managed to get the bug. I've been pleased with my progress so far, but a couple of things have bugged me enough to seek advice from the rest of y'all. 1. Contending with the use of frequently unfamiliar non-alphanumeric operators has been an uphill battle for me. I think the main reason for this is that I've had no luck in Googling up their definitions (my primary approach for dealing with every other unknown in the Haskell universe) due to their very non-alphanumeric nature. I'm curious if 1) anyone has compiled a cheat sheet of common operators and their meanings/modules, in some sort of text-search-friendly format (e.g. spelling out the operator characters, listing alternate names), or 2) a better way for searching for these things? 2. There's a lot I need to learn about good Haskell style, especially coming from a C++ background. Even my experience in Lisp seems to result in way more parentheses than Haskell coders are comfortable with. :-) In particular, I'm curious about how people actually use monadic operators. The following simple forms with the Maybe monad, for example, appear to be equivalent (hope I and QuickCheck are right about that!): foo :: Int -> Maybe Int bar :: Int -> Maybe Int baz :: Int -> Maybe Int baz n = (foo n) >>= bar baz n = bar =<< (foo n) baz n = (foo >=> bar) n baz n = (foo <=< bar) n and I'm thinking the latter two are more idiomatically written as: baz = foo >=> bar -- I think this one is my fave, naively speaking baz = bar <=< foo Yeah, so "there's more than one way to do it"--though I would never have known about =<<, >=>, and <=< from looking at the introductory material I've seen on the subject. What do people here prefer using in what circumstances? Or is everyone off using do notation or arrows instead? :-) Thanks for the help! -- O From andrewcoppin at btinternet.com Sat Nov 22 04:35:24 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Nov 22 04:29:19 2008 Subject: [Haskell-cafe] Operator cheat sheet, and monadic style q In-Reply-To: References: Message-ID: <4927D25C.3030501@btinternet.com> Owen Smith wrote: > 1. Contending with the use of frequently unfamiliar non-alphanumeric > operators has been an uphill battle for me. I think the main reason > for this is that I've had no luck in Googling up their definitions (my > primary approach for dealing with every other unknown in the Haskell > universe) due to their very non-alphanumeric nature. I'm curious if 1) > anyone has compiled a cheat sheet of common operators and their > meanings/modules, in some sort of text-search-friendly format (e.g. > spelling out the operator characters, listing alternate names), or 2) > a better way for searching for these things? > Hoogle is more likely to help you here. http://haskell.org/hoogle/ From max.rabkin at gmail.com Sat Nov 22 04:42:01 2008 From: max.rabkin at gmail.com (Max Rabkin) Date: Sat Nov 22 04:35:58 2008 Subject: [Haskell-cafe] Operator cheat sheet, and monadic style q In-Reply-To: References: Message-ID: On Sat, Nov 22, 2008 at 11:31 AM, Owen Smith wrote: > I'm a longtime Haskell-curious programmer who, after a few aborted > attempts at getting started and long nights staring at academic > papers, finally managed to get the bug. I've been pleased with my > progress so far, but a couple of things have bugged me enough to seek > advice from the rest of y'all. Welcome to our addiction! > 1. Contending with the use of frequently unfamiliar non-alphanumeric > operators has been an uphill battle for me. I think the main reason > for this is that I've had no luck in Googling up their definitions (my > primary approach for dealing with every other unknown in the Haskell > universe) due to their very non-alphanumeric nature. The solution is Hoogle (http://haskell.org/hoogle/). Hoogle allows searching not only alphanumeric operators, but all of the standard Haskell libraries, as well as some non-standard libraries on Hackage. You can search by name, package, module or type. Results link to Haddock documentation, which usually links in turn to source code. > 2. There's a lot I need to learn about good Haskell style, especially > coming from a C++ background. Even my experience in Lisp seems to > result in way more parentheses than Haskell coders are comfortable > with. :-) I also started out with too many parentheses. Don't let them bother you too much. Over time, they'll diminish. > In particular, I'm curious about how people actually use > monadic operators. The following simple forms with the Maybe monad, > for example, appear to be equivalent (hope I and QuickCheck are right > about that!): > > foo :: Int -> Maybe Int > bar :: Int -> Maybe Int > baz :: Int -> Maybe Int > > baz n = (foo n) >>= bar > baz n = bar =<< (foo n) > baz n = (foo >=> bar) n > baz n = (foo <=< bar) n > > and I'm thinking the latter two are more idiomatically written as: > > baz = foo >=> bar -- I think this one is my fave, naively speaking I think it's my fave too. > baz = bar <=< foo > > Yeah, so "there's more than one way to do it"--though I would never > have known about =<<, >=>, and <=< from looking at the introductory > material I've seen on the subject. What do people here prefer using in > what circumstances? Or is everyone off using do notation or arrows > instead? :-) I tend to use arrow or applicative notation where it applies, simply because it's more general and sometimes prettier. Use do notation when it's the easiest to understand (this will probably also diminish over time). I generally only use it when there is complex sequencing, and certainly not in this case. > Thanks for the help! > -- O --Max From lrpalmer at gmail.com Sat Nov 22 04:50:34 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sat Nov 22 04:44:31 2008 Subject: [Haskell-cafe] Operator cheat sheet, and monadic style q In-Reply-To: References: Message-ID: <7ca3f0160811220150l974597eu5151fb0c3f36dafa@mail.gmail.com> On Sat, Nov 22, 2008 at 2:31 AM, Owen Smith wrote: > 2. There's a lot I need to learn about good Haskell style, especially > coming from a C++ background. Even my experience in Lisp seems to > result in way more parentheses than Haskell coders are comfortable > with. :-) In particular, I'm curious about how people actually use > monadic operators. The following simple forms with the Maybe monad, > for example, appear to be equivalent (hope I and QuickCheck are right > about that!): > > foo :: Int -> Maybe Int > bar :: Int -> Maybe Int > baz :: Int -> Maybe Int > > baz n = (foo n) >>= bar > baz n = bar =<< (foo n) > baz n = (foo >=> bar) n > baz n = (foo <=< bar) n > > and I'm thinking the latter two are more idiomatically written as: > > baz = foo >=> bar -- I think this one is my fave, naively speaking > baz = bar <=< foo You will find many differing opinions about this; just pick one that you find pretty and elegant. My personal style is never to use >>= or >=>; only =<< and <=<. These operators are for when I want monadic operations to feel like function application, which has the data flowing right to left. When I want monadic operations to feel like sequencing, I always use do notation. This is a particular case of my general inclination to have data in my progarm flow from top to bottom and right to left. (However I still often "read" it left to right; but I am inconsistent about that, and often switch back and forth when trying to comprehend a piece of code) Luke From malcolm.wallace at cs.york.ac.uk Sat Nov 22 05:13:39 2008 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Sat Nov 22 05:08:15 2008 Subject: [Haskell-cafe] Re: [Haskell] Does GHC support the standard CPP functionalities? In-Reply-To: <200811221733344532757@163.com> References: <200811221733344532757@163.com> Message-ID: <1CE1B5AD-AE66-46FA-916C-81B2AF0C624A@cs.york.ac.uk> [moved to haskell-cafe] > {-# LANGUAGE CPP #-} > > module Packer where > > #define FLASH_APP_START 1 > #define FLASH_APP_END 2 > #define INSERT_SECTION(x) (#x, (FLASH_##x##_START, FLASH_##x##_END)) The CPP stringization operator # and the token-catenation operator ## are ANSI additions over the traditional K+R CPP. Ghc uses the - traditional flag to exclude them, because both # and ## are valid Haskell operators, and most people would not want them to be removed by the CPP preprocessor. There are also some other lexical differences between Haskell and C which make it a good ides for ghc to use cpp -traditional. However, if you really want to use ANSI additions, you can switch to cpphs, which does know about the lexical syntax of Haskell. http://haskell.org/cpphs To use it with ghc, you will need to pass the following extra options: ghc -cpp -pgmPcpphs -optP--cpp -optP-ansi Unfortunately, I'm not certain I can guarantee that the -ansi flag will take effect - it depends on whether ghc internally adds the - traditional argument before or after it. Regards, Malcolm From nominolo at googlemail.com Sat Nov 22 06:33:31 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Sat Nov 22 06:27:28 2008 Subject: [Haskell-cafe] Extensible Exceptions In-Reply-To: <4927609F.5080104@z.odi.ac> References: <1227313177.3309.6.camel@Congo> <4927609F.5080104@z.odi.ac> Message-ID: <916b84820811220333q7c2605efl76d51cea7d0f3df4@mail.gmail.com> Be careful, though. This only works if there's a single constructor for your exception type. If there are multiple, you should write it like this: thing_to_try `catch` \(e :: MyErrorType) -> case e of MyError1 _ -> ..; MyError2 _ -> ... If you write `catch` (MyError1 ...) and a MyError2 is thrown, you will get a pattern match error exception. If you want to catch multiple exceptions (of different type) at once, use the "catches" combinator. 2008/11/22 Ross Mellgren : > I think catch is now basically what catchJust was -- you can just do > >> thing_to_try `catch` (\ (ErrorCall s) -> putStrLn s) > > and it will only catch ErrorCall exceptions. > > -Ross > > > David F. Place wrote: >> >> Hi, All. >> >> I am trying to understand the new exceptions package in base-4 >> Control.Exceptions. The documentation for catchJust is the same as in >> Control.OldException including this example: >> >> result <- catchJust errorCalls thing_to_try handler >> >> Control.OldException provides the predicate errorCalls, but the new one >> does not. I don't see how to write it. >> >> Thanks for reading. >> >> Cheers, >> David >> >> _______________________________________________ >> 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 > -- Push the envelope. Watch it bend. From dokondr at gmail.com Sat Nov 22 06:40:41 2008 From: dokondr at gmail.com (Dmitri O.Kondratiev) Date: Sat Nov 22 06:34:37 2008 Subject: [Haskell-cafe] How to use Unicode strings? Message-ID: <53396d9e0811220340o6e6b27eeh4ef80e7f467c7a58@mail.gmail.com> Please advise how to write Unicode string, so this example would work: main = do putStrLn "Les signes orthographiques inclus les accents (aigus, gr?ve, circonflexe), le tr?ma, l'apostrophe, la c?dille, le trait d'union et la majuscule." I get the following error: hello.hs:4:68: lexical error in string/character literal (UTF-8 decoding error) Failed, modules loaded: none. Prelude> Also, how to read Unicode characters from standard input? Thanks! -- Dmitri O. Kondratiev dokondr@gmail.com http://www.geocities.com/dkondr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081122/f736e390/attachment.htm From lrpalmer at gmail.com Sat Nov 22 06:52:56 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sat Nov 22 06:46:52 2008 Subject: [Haskell-cafe] How to use Unicode strings? In-Reply-To: <53396d9e0811220340o6e6b27eeh4ef80e7f467c7a58@mail.gmail.com> References: <53396d9e0811220340o6e6b27eeh4ef80e7f467c7a58@mail.gmail.com> Message-ID: <7ca3f0160811220352o138723fcgadd59b8d6877b6c7@mail.gmail.com> 2008/11/22 Dmitri O.Kondratiev : > Please advise how to write Unicode string, so this example would work: > > main = do > putStrLn "Les signes orthographiques inclus les accents (aigus, gr?ve, > circonflexe), le tr?ma, l'apostrophe, la c?dille, le trait d'union et la > majuscule." That really ought to work. Is the file encoded in UTF-8 (rather than, eg. latin-1)? Luke From niklas.broberg at gmail.com Sat Nov 22 07:54:11 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sat Nov 22 07:48:07 2008 Subject: [Haskell-cafe] Fixity parsing, Template Haskell In-Reply-To: <4cf038ee0811210459j6d8238c6r73ca3a3932d902cc@mail.gmail.com> References: <4cf038ee0811210459j6d8238c6r73ca3a3932d902cc@mail.gmail.com> Message-ID: > Of course, this would require a change to Template Haskell, so a > second-best solution would be to forbid unparenthesised expressions in > my quasiquoter. Then, parsing can proceed correctly without knowing > the fixities. This would be easiest to do if haskell-src-exts changed > its AST in a similar way to described above for Template Haskell. I'm not sure I follow you here. In what way would it be simpler if HSE changes its AST to a less-information constructor? I won't do that, for the same reason you point out with TH and disadvantages when using it as a library, though I'm still curious what uses you envision and how it would be made easier. I'm still in the process of designing the fixity support for HSE, and all input is valuable. :-) Cheers, /Niklas From alexey.skladnoy at gmail.com Sat Nov 22 07:56:29 2008 From: alexey.skladnoy at gmail.com (Alexey Khudyakov) Date: Sat Nov 22 07:50:26 2008 Subject: [Haskell-cafe] How to use Unicode strings? In-Reply-To: <7ca3f0160811220352o138723fcgadd59b8d6877b6c7@mail.gmail.com> References: <53396d9e0811220340o6e6b27eeh4ef80e7f467c7a58@mail.gmail.com> <7ca3f0160811220352o138723fcgadd59b8d6877b6c7@mail.gmail.com> Message-ID: <8425cc0e0811220456i52d9d4bco35ceb81c59ad5236@mail.gmail.com> > > That really ought to work. Is the file encoded in UTF-8 (rather than, > eg. latin-1)? > This should pretend to work. Simple print functions garble unicode characters. For example : > putStrLn "?? ? ??? ???? ??? ???????? ???????" prints following output C 8 345 MB>B 20H E20;Q=K9 C=8:>4? Not pretty? Althrough Dmitri's variant seems to work fine. From voigt at tcs.inf.tu-dresden.de Sat Nov 22 08:24:33 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Sat Nov 22 08:18:30 2008 Subject: [Haskell-cafe] Re: Type question in instance of a class In-Reply-To: References: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> <1115545264.20081117010308@gmail.com> <7ca3f0160811161609t5575ee0fh6f0bfcd574467cef@mail.gmail.com> <49a77b7a0811161620h59501171of1fdc37d2d3f847f@mail.gmail.com> Message-ID: <49280811.7080503@tcs.inf.tu-dresden.de> Peter Hercek wrote: > But Haskell with Control.Exception extension has more values > of all types since they can be thrown and later caught and > investigated at that place. > > Maybe the last sentence of section 2.1 (_|_ Bottom) of > "Haskell/Denotational semantics" should be clarified better. > > http://en.wikibooks.org/wiki/Haskell/Denotational_semantics#.E2.8A.A5_Bottom > > > So when trying to use Curry-Howard isomorphism for something > in Haskell, one sould be pretty carefull what features of are > being used. Definitely. And that surfaces even in quite innocently looking programs and statements about them. The introductory example of the following technical report may be amusing in that respect: http://wwwtcs.inf.tu-dresden.de/~voigt/TUD-FI08-08.pdf Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From voigt at tcs.inf.tu-dresden.de Sat Nov 22 08:33:32 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Sat Nov 22 08:27:30 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <2f9b2d30811181951l5e3cd89ejf0ac46d39dfd1bf0@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> <7ca3f0160811181246p63ce13adneb920f4ffde06f8c@mail.gmail.com> <2f9b2d30811181951l5e3cd89ejf0ac46d39dfd1bf0@mail.gmail.com> Message-ID: <49280A2C.6070601@tcs.inf.tu-dresden.de> Ryan Ingram wrote: > On Tue, Nov 18, 2008 at 12:46 PM, Luke Palmer wrote: > >>But when these persistent data structures are used in a >>single-threaded way, why should we not hope for the performance to be >>comparable? > > > If you can guarantee single-threaded use, then you can just use ST and > implement the ephemeral structure, right? > > >>It may not be easy, but just saying "they are persistent" is not >>really an excuse. > > > You can generally make a persistent data structure with the same > asymptotic bounds as the ephemeral structure, ... I would be very careful with the "generally" here. At least, I am not aware that this has been proved to always be possible. Also, in assertions about "the same asymptotic bounds", in this and a previous post in this thread, a distinction is important between worst-case and amortized costs. Just to complete the picture... Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From mad.one at gmail.com Sat Nov 22 09:07:42 2008 From: mad.one at gmail.com (Austin Seipp) Date: Sat Nov 22 09:01:44 2008 Subject: [Haskell-cafe] How to use Unicode strings? In-Reply-To: <53396d9e0811220340o6e6b27eeh4ef80e7f467c7a58@mail.gmail.com> References: <53396d9e0811220340o6e6b27eeh4ef80e7f467c7a58@mail.gmail.com> Message-ID: <1227362645-sup-9780@existential.local> Excerpts from Dmitri O.Kondratiev's message of Sat Nov 22 05:40:41 -0600 2008: > Please advise how to write Unicode string, so this example would work: > > main = do > putStrLn "Les signes orthographiques inclus les accents (aigus, gr?ve, > circonflexe), le tr?ma, l'apostrophe, la c?dille, le trait d'union et la > majuscule." > > I get the following error: > hello.hs:4:68: > lexical error in string/character literal (UTF-8 decoding error) > Failed, modules loaded: none. > Prelude> > > Also, how to read Unicode characters from standard input? > > Thanks! > Hi, Check out the utf8-string package on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utf8-string In particular, you probably want the System.IO.UTF8 functions, which are identical to to their non-utf8 counterparts in System.IO except, well, they handle unicode properly. More specifically, you will probably want to mainly look at Codec.Binary.UTF8.String.encodeString and decodeString, respectively (in fact, most of the System.IO.UTF8 functions are defined in terms of these, e.g. 'putStrLn x = IO.putStrLn (encodeString x)' and 'getLine = liftM decodeString IO.getLine'.) Austin From duncan.coutts at worc.ox.ac.uk Sat Nov 22 09:11:14 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Nov 22 09:05:15 2008 Subject: [Haskell-cafe] Do I need an account to report build of Hacakge packages? In-Reply-To: References: Message-ID: <1227363074.7124.216.camel@localhost> On Fri, 2008-11-21 at 16:12 -0800, Ahn, Ki Yung wrote: > I am just curious about how cabal report works. > > I recently figured out that there is a report command in cabal and it > reports the reports generated by --build-reports option when building a > package. > > Is this because I don't have an account on Hackage yet, or because of > some other reasons? It's a feature that exists in the client that has no corresponding implementation on the server-side yet. There is a new hackage-server in development that can accept build reports uploaded by "cabal report". > And if I make an account, where how I put that information in cabal > config file? You only need an account for uploading packages. If you do not want to have to enter your user name or password interactively when you run "cabal upload" then you can put them in the config file: username: password: You can use one field without the other field and "cabal upload" will prompt for the one you did not supply. So you don't need to save your password in the config file. > I've looked into the cabal config file and tried to change this myself > before, but it wasn't very self explanatory to me. For instance, I > tried to make the build-reports on by default, deleting haskell comment > like double dashes "--" and put True flag after the colon, but keep > getting parse error from cabal. I looked up the manual but it says that > the config file is self explanatory, which isn't to me at all. Are > there any documentations on this available anywhere? There is some problems in the config file parsing code it seems. The config file parsing code is derived automatically from the command line parsing code but imperfectly at the moment. For example --build-reports is a boolean value flag but with no argument and these do not seem to be converted correctly into config file fields. > === error messages when I tried to report the build log === > > kyagrd@kyagrd:~$ cabal report Yes. The current hackage server does not support uploading build reports. Duncan From voigt at tcs.inf.tu-dresden.de Sat Nov 22 09:20:17 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Sat Nov 22 09:14:13 2008 Subject: [Haskell-cafe] varargs zip In-Reply-To: <3c6288ab0811210822l208217cgd7db9fe0d5cb6020@mail.gmail.com> References: <42784f260811210640i5b06c70bqb57b37efaa94d0ef@mail.gmail.com> <3c6288ab0811210822l208217cgd7db9fe0d5cb6020@mail.gmail.com> Message-ID: <49281521.8010902@tcs.inf.tu-dresden.de> Sean Leather wrote: > EMGM [1] has a generic zipWith [2]: > >> zipWith :: FRep3 ZipWith f => (a -> b -> c) -> f a -> f b -> Maybe (f c) > > This is generic according to the container type 'f'. A particular > specialization of this is zip: > >> zip :: FRep3 ZipWith f => f a -> f b -> Maybe (f (a, b)) Also, module Data.Zippable of package http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bff has: tryZip :: Zippable f => f a -> f b -> Either String (f (a,b)) where "Either String" plays the role of "Maybe" above. And for the underlying Zippable class, Joachim Breitner has implemented an automatic TH deriver (makeZippable) using the derive-package. So no manual boilerplate at all is necessary to use this version of generic zip. (And there is also a tryZipWith.) Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From voigt at tcs.inf.tu-dresden.de Sat Nov 22 09:22:56 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Sat Nov 22 09:16:52 2008 Subject: [Haskell-cafe] How to use Unicode strings? In-Reply-To: <8425cc0e0811220456i52d9d4bco35ceb81c59ad5236@mail.gmail.com> References: <53396d9e0811220340o6e6b27eeh4ef80e7f467c7a58@mail.gmail.com> <7ca3f0160811220352o138723fcgadd59b8d6877b6c7@mail.gmail.com> <8425cc0e0811220456i52d9d4bco35ceb81c59ad5236@mail.gmail.com> Message-ID: <492815C0.5040508@tcs.inf.tu-dresden.de> Alexey Khudyakov wrote: >>putStrLn "?? ? ??? ???? ??? ???????? ???????" :-) -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From d at vidplace.com Sat Nov 22 09:49:34 2008 From: d at vidplace.com (David F. Place) Date: Sat Nov 22 09:42:30 2008 Subject: [Haskell-cafe] Extensible Exceptions In-Reply-To: <916b84820811220333q7c2605efl76d51cea7d0f3df4@mail.gmail.com> References: <1227313177.3309.6.camel@Congo> <4927609F.5080104@z.odi.ac> <916b84820811220333q7c2605efl76d51cea7d0f3df4@mail.gmail.com> Message-ID: <1227365374.3184.7.camel@Congo> On Sat, 2008-11-22 at 11:33 +0000, Thomas Schilling wrote: > Be careful, though. This only works if there's a single constructor > for your exception type. If there are multiple, you should write it > like this: > > thing_to_try `catch` \(e :: MyErrorType) -> case e of MyError1 _ -> > ..; MyError2 _ -> ... > > If you write `catch` (MyError1 ...) and a MyError2 is thrown, you will > get a pattern match error exception. > Since I am trying to replicate the behavior of errorCalls, I have only the single constructor ErrorCall to worry about. I don't understand though, how this works: I have a predicate errorCalls e@(ErrorCall _) = Just e In the following transcript it seems to work correctly even if something beside ErrorCall is thrown. Passing NonTermination to errorCalls get a type error as expected. Why does it work inside tryJust? *Main> tryJust errorCalls $ print $ [] !! 23 tryJust errorCalls $ print $ [] !! 23^JLeft Prelude.(!!): index too large *Main> tryJust errorCalls $ print $ throw NonTermination tryJust errorCalls $ print $ throw NonTermination^J*** Exception: <> *Main> errorCalls (ErrorCall "What?") errorCalls (ErrorCall "What?")^JJust What? *Main> errorCalls NonTermination errorCalls NonTermination^J :1:11: Couldn't match expected type `ErrorCall' against inferred type `NonTermination' In the first argument of `errorCalls', namely `NonTermination' In the expression: errorCalls NonTermination In the definition of `it': it = errorCalls NonTermination From claus.reinke at talk21.com Sat Nov 22 10:11:34 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Sat Nov 22 10:05:35 2008 Subject: [Haskell-cafe] Do I need an account to report build of Hacakgepackages? References: <1227363074.7124.216.camel@localhost> Message-ID: <9DF84EC8D97E4270902E152E26E04213@cr3lt> > You only need an account for uploading packages. If you do not want to > have to enter your user name or password interactively when you run > "cabal upload" then you can put them in the config file: > > username: > password: That sounds like a very bad idea, and should not be encouraged! Any compromised uploader machine with stored passwords can be used to upload compromising code, which will propagate to all downloaders. One bad-apple package installed unwittingly on one uploader machine with stored passwords could compromise all of Haskell land. Claus From duncan.coutts at worc.ox.ac.uk Sat Nov 22 10:24:19 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Nov 22 10:18:20 2008 Subject: [Haskell-cafe] Do I need an account to report build of Hacakgepackages? In-Reply-To: <9DF84EC8D97E4270902E152E26E04213@cr3lt> References: <1227363074.7124.216.camel@localhost> <9DF84EC8D97E4270902E152E26E04213@cr3lt> Message-ID: <1227367459.7124.220.camel@localhost> On Sat, 2008-11-22 at 15:11 +0000, Claus Reinke wrote: > > You only need an account for uploading packages. If you do not want to > > have to enter your user name or password interactively when you run > > "cabal upload" then you can put them in the config file: > > > > username: > > password: > > That sounds like a very bad idea, and should not be encouraged! > Any compromised uploader machine with stored passwords can > be used to upload compromising code, which will propagate to > all downloaders. One bad-apple package installed unwittingly on > one uploader machine with stored passwords could compromise > all of Haskell land. We've got bigger security issues than this. I'd welcome someone to spend some time implementing some of the obvious and sensible ideas we've discussed to improve the situation. Duncan From nominolo at googlemail.com Sat Nov 22 10:27:54 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Sat Nov 22 10:21:50 2008 Subject: [Haskell-cafe] Extensible Exceptions In-Reply-To: <1227365374.3184.7.camel@Congo> References: <1227313177.3309.6.camel@Congo> <4927609F.5080104@z.odi.ac> <916b84820811220333q7c2605efl76d51cea7d0f3df4@mail.gmail.com> <1227365374.3184.7.camel@Congo> Message-ID: <916b84820811220727n344c977am7aaa97cdfc78b18a@mail.gmail.com> 2008/11/22 David F. Place : > On Sat, 2008-11-22 at 11:33 +0000, Thomas Schilling wrote: >> Be careful, though. This only works if there's a single constructor >> for your exception type. If there are multiple, you should write it >> like this: >> >> thing_to_try `catch` \(e :: MyErrorType) -> case e of MyError1 _ -> >> ..; MyError2 _ -> ... >> >> If you write `catch` (MyError1 ...) and a MyError2 is thrown, you will >> get a pattern match error exception. >> > > Since I am trying to replicate the behavior of errorCalls, I have only > the single constructor ErrorCall to worry about. I don't understand > though, how this works: I have a predicate > > errorCalls e@(ErrorCall _) = Just e > > In the following transcript it seems to work correctly even if something > beside ErrorCall is thrown. Passing NonTermination to errorCalls get a > type error as expected. Why does it work inside tryJust? > > > *Main> tryJust errorCalls $ print $ [] !! 23 > tryJust errorCalls $ print $ [] !! 23^JLeft Prelude.(!!): index > too large > > *Main> tryJust errorCalls $ print $ throw NonTermination > tryJust errorCalls $ print $ throw NonTermination^J*** > Exception: <> It doesn't. The last line is printed by GHCi. Note the missing "Exception: " in the first call. From antti-juhani at kaijanaho.fi Sat Nov 22 10:45:18 2008 From: antti-juhani at kaijanaho.fi (Antti-Juhani Kaijanaho) Date: Sat Nov 22 10:39:17 2008 Subject: [Haskell-cafe] Do I need an account to report build of Hacakgepackages? In-Reply-To: <9DF84EC8D97E4270902E152E26E04213@cr3lt> References: <1227363074.7124.216.camel@localhost> <9DF84EC8D97E4270902E152E26E04213@cr3lt> Message-ID: <20081122154518.GB26240@kukkaseppele.kaijanaho.fi> On Sat, Nov 22, 2008 at 03:11:34PM -0000, Claus Reinke wrote: >> You only need an account for uploading packages. If you do not want to >> have to enter your user name or password interactively when you run >> "cabal upload" then you can put them in the config file: >> >> username: >> password: > > That sounds like a very bad idea, and should not be encouraged! Agreed. However... > Any compromised uploader machine with stored passwords can > be used to upload compromising code, which will propagate to all > downloaders. It doesn't really matter whether a compromised machine stores a password or not. If you upload anything using a compromised machine, the attacker has the opportunity to learn your password. Also, Hackage doesn't use SSL/TLS, so compromising a machine isn't necessary for learning Hackage passwords. -- Antti-Juhani Kaijanaho, Jyv?skyl?, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ From d at vidplace.com Sat Nov 22 10:55:16 2008 From: d at vidplace.com (David F. Place) Date: Sat Nov 22 10:48:07 2008 Subject: [Haskell-cafe] Extensible Exceptions In-Reply-To: <916b84820811220727n344c977am7aaa97cdfc78b18a@mail.gmail.com> References: <1227313177.3309.6.camel@Congo> <4927609F.5080104@z.odi.ac> <916b84820811220333q7c2605efl76d51cea7d0f3df4@mail.gmail.com> <1227365374.3184.7.camel@Congo> <916b84820811220727n344c977am7aaa97cdfc78b18a@mail.gmail.com> Message-ID: <1227369316.3184.9.camel@Congo> On Sat, 2008-11-22 at 15:27 +0000, Thomas Schilling wrote: > > *Main> tryJust errorCalls $ print $ [] !! 23 > > tryJust errorCalls $ print $ [] !! 23^JLeft Prelude.(!!): > index > > too large > > > > *Main> tryJust errorCalls $ print $ throw NonTermination > > tryJust errorCalls $ print $ throw NonTermination^J*** > > Exception: <> > > It doesn't. The last line is printed by GHCi. > > Note the missing "Exception: " in the first call. > !! uses error, so the first call shouldn't have "Exception: ." It is handled by tryJust and not rethrown. From reiner.pope at gmail.com Sat Nov 22 11:02:32 2008 From: reiner.pope at gmail.com (Reiner Pope) Date: Sat Nov 22 10:56:29 2008 Subject: [Haskell-cafe] Fixity parsing, Template Haskell In-Reply-To: References: <4cf038ee0811210459j6d8238c6r73ca3a3932d902cc@mail.gmail.com> Message-ID: <4cf038ee0811220802w1f3040ecl174451f3f26a3a02@mail.gmail.com> It seems to me that fixity information behaves more like semantics than like syntax. For instance, fixities may be imported, and obey namespacing rules. Knowing and correctly handling these rules seems beyond the scope of a mere parser: I would hope that a single Haskell file could be parsed without reference to any files, and fixity declarations seem to be just about the only thing which prevent this -- hence my suggestion to change the AST in order to regain this property. The use I envision of it is as I described: writing a quasiquoter using HSE to parse the user's Haskell expressions. The problem is that, for such a case, HSE (or any other parser) is forced to parse infix expressions for which it cannot possibly know the correct fixities. Any result with more information than the list form I gave would be a lie. I realise that I don't know how fixities are implemented in Haskell compilers, so perhaps I'm misunderstanding how they are treated. Cheers, Reiner On Sat, Nov 22, 2008 at 11:54 PM, Niklas Broberg wrote: >> Of course, this would require a change to Template Haskell, so a >> second-best solution would be to forbid unparenthesised expressions in >> my quasiquoter. Then, parsing can proceed correctly without knowing >> the fixities. This would be easiest to do if haskell-src-exts changed >> its AST in a similar way to described above for Template Haskell. > > I'm not sure I follow you here. In what way would it be simpler if HSE > changes its AST to a less-information constructor? I won't do that, > for the same reason you point out with TH and disadvantages when using > it as a library, though I'm still curious what uses you envision and > how it would be made easier. I'm still in the process of designing the > fixity support for HSE, and all input is valuable. :-) > > Cheers, > > /Niklas > From claus.reinke at talk21.com Sat Nov 22 11:29:49 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Sat Nov 22 11:23:53 2008 Subject: [Haskell-cafe] Do I need an account to report build ofHacakgepackages? References: <1227363074.7124.216.camel@localhost><9DF84EC8D97E4270902E152E26E04213@cr3lt> <20081122154518.GB26240@kukkaseppele.kaijanaho.fi> Message-ID: >> Any compromised uploader machine with stored passwords can >> be used to upload compromising code, which will propagate to all >> downloaders. > > It doesn't really matter whether a compromised machine stores a password or > not. If you upload anything using a compromised machine, the attacker > has the opportunity to learn your password. True. But storing the password means that the owner doesn't need to initiate an upload, nor does the attacker need to capture keypresses, listen on connections, identify uploads/logins/passwords in the captured date, or do anything at all non-trivial, platform-specific or persistent (propagation could ignore the owner's machine). > Also, Hackage doesn't use SSL/TLS, so compromising a machine isn't > necessary for learning Hackage passwords. As Duncan says, an overall security review would be good, the sooner, the better. But that shouldn't prevent incremental improvements whereever they are found. One just needs to keep in mind that they make attacks harder/less likely, not impossible. Encouraging all users to keep an eye on the obvious holes may also make it more likely that the less obvious holes are noticed and addressed. Claus From dons at galois.com Sat Nov 22 13:02:35 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 22 12:56:28 2008 Subject: [Haskell-cafe] How to use Unicode strings? In-Reply-To: <8425cc0e0811220456i52d9d4bco35ceb81c59ad5236@mail.gmail.com> References: <53396d9e0811220340o6e6b27eeh4ef80e7f467c7a58@mail.gmail.com> <7ca3f0160811220352o138723fcgadd59b8d6877b6c7@mail.gmail.com> <8425cc0e0811220456i52d9d4bco35ceb81c59ad5236@mail.gmail.com> Message-ID: <20081122180235.GA17052@scytale.galois.com> alexey.skladnoy: > > > > That really ought to work. Is the file encoded in UTF-8 (rather than, > > eg. latin-1)? > > > This should pretend to work. Simple print functions garble unicode characters. > For example : > > > putStrLn "?? ? ??? ???? ??? ???????? ???????" > > prints following output > > C 8 345 MB>B 20H E20;Q=K9 C=8:>4? > > Not pretty? Althrough Dmitri's variant seems to work fine. Use the UTF8 printing functions, import qualified System.IO.UTF8 as U main = U.putStrLn "?? ? ??? ???? ??? ???????? ???????" Running this, *Main> main ?? ? ??? ???? ??? ???????? ??????? -- Don From ryani.spam at gmail.com Sat Nov 22 14:01:33 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sat Nov 22 13:55:28 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <49280A2C.6070601@tcs.inf.tu-dresden.de> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> <7ca3f0160811181246p63ce13adneb920f4ffde06f8c@mail.gmail.com> <2f9b2d30811181951l5e3cd89ejf0ac46d39dfd1bf0@mail.gmail.com> <49280A2C.6070601@tcs.inf.tu-dresden.de> Message-ID: <2f9b2d30811221101k3845cc09w6be8ceae5977c497@mail.gmail.com> On Sat, Nov 22, 2008 at 5:33 AM, Janis Voigtlaender wrote: >> You can generally make a persistent data structure with the same >> asymptotic bounds as the ephemeral structure, ... > > I would be very careful with the "generally" here. At least, I am not > aware that this has been proved to always be possible. Here's an informal proof: You can use an intmap to emulate pointers, to turn any ephemeral data structure into a persistent one. That adds at most a log-n factor to lookups and updates. For many structures, this is enough to prove asymptotic bounds equivalence. However, the standard 'pointer' model for ephemeral structures makes the assumption that memory size is limited; otherwise you have to add a log(n) factor there anyways, both to hold the large pointer values that get generated and to actually send the bits to the memory bus. Given this assumption you can take log(memory size) as a constant and argue that pointer lookup and update via the map is O(1). > Also, in > assertions about "the same asymptotic bounds", in this and a previous > post in this thread, a distinction is important between worst-case and > amortized costs. Just to complete the picture... That's true, but I think the more important distinction is the constant attached to the big O; persistent data structures tend to have much worse constant factors and those factors translate to a general 2x-3x slowdown. It's often true that a worse asymptotic cost algorithm is better because the constant factors are much better and the expected N in your program is small enough. -- ryan From duncan.coutts at worc.ox.ac.uk Sat Nov 22 14:16:13 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Nov 22 14:10:13 2008 Subject: [Haskell-cafe] How to use Unicode strings? In-Reply-To: <20081122180235.GA17052@scytale.galois.com> References: <53396d9e0811220340o6e6b27eeh4ef80e7f467c7a58@mail.gmail.com> <7ca3f0160811220352o138723fcgadd59b8d6877b6c7@mail.gmail.com> <8425cc0e0811220456i52d9d4bco35ceb81c59ad5236@mail.gmail.com> <20081122180235.GA17052@scytale.galois.com> Message-ID: <1227381373.7124.239.camel@localhost> On Sat, 2008-11-22 at 10:02 -0800, Don Stewart wrote: > Use the UTF8 printing functions, > > import qualified System.IO.UTF8 as U > > main = U.putStrLn "?? ? ??? ???? ??? ???????? ???????" > > Running this, > > *Main> main > ?? ? ??? ???? ??? ???????? ??????? This upsets me. We need to get on with doing this properly. The System.IO.UTF8 module is a useful interim workaround but we're not using it properly most of the time. It is right when you're working with a text file that you know to be in the UTF-8 format. For example .cabal files are UTF-8, irrespective of the platform or the system locale. It is not right when working with the terminal. The encoding of the terminal is given by the locale. We cannot statically declare that it is UTF-8. The right thing to do is to make Prelude.putStrLn do the right thing. We had a long discussion on how to fix the H98 IO functions to do this better. We just need to get on with it, or we'll end up with too many cases of people using System.IO.UTF8 inappropriately. For the case where System.IO.UTF8 is right we probably still want a more general solution, like a handle setting for the encoding. Duncan From ninegua at gmail.com Sat Nov 22 15:31:17 2008 From: ninegua at gmail.com (Paul L) Date: Sat Nov 22 15:25:14 2008 Subject: [Haskell-cafe] GHC 6.10 and OpenGL Message-ID: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> Hi everyone, It's sad to see the OpenGL binding being dropped from GHC binary installers starting from 6.10. Though this issue has been brought up and discussed before, I'm sure a lot of people who based their work on OpenGL would share the same sympathy. I'm not here to argue whether this decision by GHC dev team is right or wrong, but what's really causing the pain is that the OpenGL binding doesn't have its own binary installer for Windows, and compilation from source on this platform is non-trivial. I wouldn't recommend doing it for ordinary users. So my question is, are we going to see a binary installer for OpenGL binding provided separately from either HOpenGL site, or Hackage? Or even the GHC installation page? -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale From dons at galois.com Sat Nov 22 15:34:41 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 22 15:28:34 2008 Subject: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL In-Reply-To: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> References: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> Message-ID: <20081122203441.GG17052@scytale.galois.com> ninegua: > Hi everyone, > > It's sad to see the OpenGL binding being dropped from GHC binary > installers starting from 6.10. Though this issue has been brought up > and discussed before, I'm sure a lot of people who based their work on > OpenGL would share the same sympathy. $ cabal install OpenGL > I'm not here to argue whether this decision by GHC dev team is right > or wrong, but what's really causing the pain is that the OpenGL > binding doesn't have its own binary installer for Windows, and > compilation from source on this platform is non-trivial. I wouldn't > recommend doing it for ordinary users. > So my question is, are we going to see a binary installer for OpenGL > binding provided separately from either HOpenGL site, or Hackage? Or > even the GHC installation page? This would be a job for the Windows distribution team to sort out. Each other distro addresses the native packaging problem by developing packages, and what is needed for a similar team for Windows, to provide Windows packages. -- Don From lemming at henning-thielemann.de Sat Nov 22 16:00:08 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Nov 22 15:54:04 2008 Subject: [Haskell-cafe] Extensible Exceptions In-Reply-To: <916b84820811220333q7c2605efl76d51cea7d0f3df4@mail.gmail.com> References: <1227313177.3309.6.camel@Congo> <4927609F.5080104@z.odi.ac> <916b84820811220333q7c2605efl76d51cea7d0f3df4@mail.gmail.com> Message-ID: On Sat, 22 Nov 2008, Thomas Schilling wrote: > Be careful, though. This only works if there's a single constructor > for your exception type. If there are multiple, you should write it > like this: > > thing_to_try `catch` \(e :: MyErrorType) -> case e of MyError1 _ -> > ..; MyError2 _ -> ... > > If you write `catch` (MyError1 ...) and a MyError2 is thrown, you will > get a pattern match error exception. A "pattern match exception" or "pattern match error"? I mean, not handling a certain pattern is a programming error not an exceptional condition at runtime. Thus there is no need to throw a "pattern match exception" which is catched and handled somewhere else. From byorgey at seas.upenn.edu Sat Nov 22 16:09:12 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Nov 22 16:03:08 2008 Subject: [Haskell-cafe] Haskell Weekly News: Issue 94 - November 22, 2008 Message-ID: <20081122210912.GA5560@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20081122 Issue 94 - November 22, 2008 --------------------------------------------------------------------------- Welcome to issue 94 of HWN, a newsletter covering developments in the [1]Haskell community. Lots of interesting reading this week! Martin Escardo writes about [2]finite search over infinite search spaces expressed as a monad; Conal Elliott writes about [3]the unambiguous choice operator and [4]merging partial values; Luke Palmer on [5]restricted data types and [6]Udon, his system for universal distributed object management; a post about [7]incremental parsing in Yi; Ryan Ingram on [8]parametric higher-order abstract syntax; Issue #12 of [9]the Monad.Reader; and much more! Announcements The Monad.Reader - Issue 12: Summer of Code Special. Wouter Swierstra [10]announced Issue 12 of [11]the Monad.Reader, featuring articles by Max Bolingbroke, Roman Cheplyaka, and Neil Mitchell describing their Summer of Code projects. Turbinado V0.1. Alson Kemp [12]announced the release of [13]Turbinado, an MVC web framework for Haskell. EEConfig-1.0. Bartosz Wojcik [14]announced the release of [15]EEConfig, a simple library for reading parameters from a configuration file. Discussion Proof of a multi-threaded application. Silviu Andrica [16]asked about the possibility of proving the correctness of a multi-threaded application written in Haskell, leading to a discussion of STM, model checking, and related issues. Monadic bind with associated types + PHOAS?. Ryan Ingram [17]wrote about using parametric higher-order abstract syntax to get the benefits of HOAS (using the embedding language to express binding and substitution) while still being able to inspect or optimize the resulting expressions. Blog noise [18]Haskell news from the [19]blogosphere. * Ashish Hanwadikar: [20]More on Haskell DSL. * Real-World Haskell: [21]Real World Haskell in the Wild!. * Conal Elliott: [22]Merging partial values. * John Goerzen (CosmicRay): [23]If Programming Languages Were Christmas Carols. * Conal Elliott: [24]Functional concurrency with unambiguous choice. * >>> Martin Escardo: [25]A Haskell monad for infinite search in finite time. * The GHC Team: [26]Redesigning GHC's build system. * Luke Palmer: [27]Restricted Data Types. * Yi: [28]Incremental Parsing in Yi. * Roman Cheplyaka: [29]The Monad Reader, SoC special. * Darcs: [30]camp irregular news #1. * Eric Kow (kowey): [31]iterative committing. * >>> Joey Hess: [32]a year of haskell (not really). * FP Lunch: [33]The origin of species. * Luke Palmer: [34]Udon Sketch #2. * John Goerzen (CosmicRay): [35]Real World Haskell Update. * Real-World Haskell: [36]When will you see us on bookstore shelves?. * Paul Potts: [37]Reading Real World Haskell. * Darcs: [38]darcs 2.1.2 released!. * Darcs: [39]darcs weekly news #12. * Russell O'Connor: [40]Haskell Lesson. * Conal Elliott: [41]Enhancing a Zip. * Conal Elliott: [42]Proofs for left fold zipping. * >>> Andrew Birkett: [43]Why do they call it: Referentially transparent. * >>> Andrew Birkett: [44]Why do they call it: Referentially transparent (II). Quotes of the Week * dons: instance Ord OCaml, oh wait. hang on. OCaml can't do that. * BONUS: as you can see, one of the best parts of Haskell is #haskell. * ddarius: head [] :: FlyingMonkeys About the Haskell Weekly News New editions are posted to [45]the Haskell mailing list as well as to [46]the Haskell Sequence and [47]Planet Haskell. [48]RSS is also available, and headlines appear on [49]haskell.org. To help create new editions of this newsletter, please see the information on [50]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [51]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://math.andrej.com/2008/11/21/a-haskell-monad-for-infinite-search-in-finite-time/ 3. http://feeds.feedburner.com/~r/conal/~3/461480571/ 4. http://feeds.feedburner.com/~r/conal/~3/461534658/ 5. http://lukepalmer.wordpress.com/2008/11/20/restricted-data-types/ 6. http://lukepalmer.wordpress.com/2008/11/19/udon-sketch-2/ 7. http://yi-editor.blogspot.com/2008/11/incremental-parsing-in-yi.html 8. http://www.haskell.org//pipermail/haskell-cafe/2008-November/050768.html 9. http://www.haskell.org/haskellwiki/The_Monad.Reader 10. http://www.haskell.org//pipermail/haskell-cafe/2008-November/050786.html 11. http://www.haskell.org/haskellwiki/The_Monad.Reader 12. http://www.haskell.org//pipermail/haskell/2008-November/020811.html 13. http://www.turbinado.org/ 14. http://www.haskell.org//pipermail/haskell/2008-November/020810.html 15. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/EEConfig 16. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/47728 17. http://www.haskell.org//pipermail/haskell-cafe/2008-November/050768.html 18. http://planet.haskell.org/ 19. http://haskell.org/haskellwiki/Blog_articles 20. http://feedproxy.google.com/~r/typepad/ahanwadi/ashishs_niti/~3/n41w6S_82SE/more-on-haskell.html 21. http://www.realworldhaskell.org/blog/2008/11/22/real-world-haskell-in-the-wild/ 22. http://feeds.feedburner.com/~r/conal/~3/461534658/ 23. http://changelog.complete.org/archives/825-if-programming-languages-were-christmas-carols 24. http://feeds.feedburner.com/~r/conal/~3/461480571/ 25. http://math.andrej.com/2008/11/21/a-haskell-monad-for-infinite-search-in-finite-time/ 26. http://ghcmutterings.wordpress.com/2008/11/21/redesigning-ghcs-build-system/ 27. http://lukepalmer.wordpress.com/2008/11/20/restricted-data-types/ 28. http://yi-editor.blogspot.com/2008/11/incremental-parsing-in-yi.html 29. http://physics-dph.blogspot.com/2008/11/monad-reader-soc-special.html 30. http://blog.darcs.net/2008/11/camp-irregular-news-1.html 31. http://koweycode.blogspot.com/2008/11/iterative-commiting.html 32. http://kitenet.net/~joey/blog/entry/a_year_of_haskell___40__not_really__41__/ 33. http://sneezy.cs.nott.ac.uk/fplunch/weblog/?p=132 34. http://lukepalmer.wordpress.com/2008/11/19/udon-sketch-2/ 35. http://changelog.complete.org/archives/814-real-world-haskell-update 36. http://www.realworldhaskell.org/blog/2008/11/18/when-will-you-see-us-on-bookstore-shelves/ 37. http://praisecurseandrecurse.blogspot.com/2008/11/reading-real-world-haskell.html 38. http://blog.darcs.net/2008/11/darcs-212-released.html 39. http://blog.darcs.net/2008/11/darcs-weekly-news-12.html 40. http://r6.ca/blog/20081116T213644Z.html 41. http://feeds.feedburner.com/~r/conal/~3/454447926/ 42. http://feeds.feedburner.com/~r/conal/~3/454297817/ 43. http://www.nobugs.org/blog/archives/2008/11/12/why-do-they-call-it-referentially-transparent/ 44. http://www.nobugs.org/blog/archives/2008/11/12/why-do-they-call-it-referentially-transparent-ii/ 45. http://www.haskell.org/mailman/listinfo/haskell 46. http://sequence.complete.org/ 47. http://planet.haskell.org/ 48. http://sequence.complete.org/node/feed 49. http://haskell.org/ 50. http://haskell.org/haskellwiki/HWN 51. http://code.haskell.org/~byorgey/code/hwn/ From jason.dusek at gmail.com Sat Nov 22 16:20:58 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sat Nov 22 16:14:54 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <2f9b2d30811221101k3845cc09w6be8ceae5977c497@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> <7ca3f0160811181246p63ce13adneb920f4ffde06f8c@mail.gmail.com> <2f9b2d30811181951l5e3cd89ejf0ac46d39dfd1bf0@mail.gmail.com> <49280A2C.6070601@tcs.inf.tu-dresden.de> <2f9b2d30811221101k3845cc09w6be8ceae5977c497@mail.gmail.com> Message-ID: <42784f260811221320r5b4dbf58le167cc645f37b73b@mail.gmail.com> Ryan Ingram wrote: > ...persistent data structures tend to have much worse constant > factors and those factors translate to a general 2x-3x > slowdown. Can you explain why that is, or provide a citation for it? It's not something I've found easy to Google. -- _jsn From john at n-brain.net Sat Nov 22 16:23:16 2008 From: john at n-brain.net (John A. De Goes) Date: Sat Nov 22 16:17:11 2008 Subject: [Haskell-cafe] Fixity parsing, Template Haskell In-Reply-To: <4cf038ee0811220802w1f3040ecl174451f3f26a3a02@mail.gmail.com> References: <4cf038ee0811210459j6d8238c6r73ca3a3932d902cc@mail.gmail.com> <4cf038ee0811220802w1f3040ecl174451f3f26a3a02@mail.gmail.com> Message-ID: Though many see it as "losing" information, I agree wholeheartedly with your proposal to change the AST. It's better to have an AST that conveys less information, but truthfully, than to have an AST that purports to convey more information, when in fact that information is false. In most languages, some things just can't be known at parse time. They need to be resolved later. In this case, the most important thing is following the principle of least surprise: A Haskell expression inside a quasiquote should work the same as a Haskell expression outside a quasiquote. Violating the "principle of least surprise" is one of the most grievous mistakes language (and interface) designers make. Regards, John A. De Goes N-BRAIN, Inc. http://www.n-brain.net [n minds are better than n-1] On Nov 22, 2008, at 9:02 AM, Reiner Pope wrote: > It seems to me that fixity information behaves more like semantics > than like syntax. For instance, fixities may be imported, and obey > namespacing rules. Knowing and correctly handling these rules seems > beyond the scope of a mere parser: I would hope that a single Haskell > file could be parsed without reference to any files, and fixity > declarations seem to be just about the only thing which prevent this > -- hence my suggestion to change the AST in order to regain this > property. > > The use I envision of it is as I described: writing a quasiquoter > using HSE to parse the user's Haskell expressions. The problem is > that, for such a case, HSE (or any other parser) is forced to parse > infix expressions for which it cannot possibly know the correct > fixities. Any result with more information than the list form I gave > would be a lie. > > I realise that I don't know how fixities are implemented in Haskell > compilers, so perhaps I'm misunderstanding how they are treated. > > Cheers, > > Reiner > > On Sat, Nov 22, 2008 at 11:54 PM, Niklas Broberg > wrote: >>> Of course, this would require a change to Template Haskell, so a >>> second-best solution would be to forbid unparenthesised >>> expressions in >>> my quasiquoter. Then, parsing can proceed correctly without knowing >>> the fixities. This would be easiest to do if haskell-src-exts >>> changed >>> its AST in a similar way to described above for Template Haskell. >> >> I'm not sure I follow you here. In what way would it be simpler if >> HSE >> changes its AST to a less-information constructor? I won't do that, >> for the same reason you point out with TH and disadvantages when >> using >> it as a library, though I'm still curious what uses you envision and >> how it would be made easier. I'm still in the process of designing >> the >> fixity support for HSE, and all input is valuable. :-) >> >> Cheers, >> >> /Niklas >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From briqueabraque at yahoo.com Sat Nov 22 16:32:35 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Sat Nov 22 16:26:36 2008 Subject: [Haskell-cafe] Re: How to use Unicode strings? In-Reply-To: <53396d9e0811220340o6e6b27eeh4ef80e7f467c7a58@mail.gmail.com> References: <53396d9e0811220340o6e6b27eeh4ef80e7f467c7a58@mail.gmail.com> Message-ID: > Please advise how to write Unicode string, so this example would work: > > main = do > putStrLn "Les signes orthographiques inclus les accents (aigus, gr?ve, > circonflexe), le tr?ma, l'apostrophe, la c?dille, le trait d'union et la > majuscule." > (...) Besides the Haskell stuff, you probably want to check if your terminal outputs utf-8. I use a nice X terminal named 'mlterm'. It's main goal is to support unicode. But I don't know enough to tell you how to check your terminal, or even if just changing to mlterm will always work. Sometimes, I wonder why distributions don't just agree on considering support for anything but utf-8 a bug (except in 'iconv', of course). Well, there's probably someone out there who would have problems with that, and I don't want problems for anyone. But I hope their problems would be worst than mine trying to deal with different encodings. Best, Maur?cio From lemming at henning-thielemann.de Sat Nov 22 16:36:28 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Nov 22 16:30:24 2008 Subject: [Haskell-cafe] Re: Type question in instance of a class In-Reply-To: <49280811.7080503@tcs.inf.tu-dresden.de> References: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> <1115545264.20081117010308@gmail.com> <7ca3f0160811161609t5575ee0fh6f0bfcd574467cef@mail.gmail.com> <49a77b7a0811161620h59501171of1fdc37d2d3f847f@mail.gmail.com> <49280811.7080503@tcs.inf.tu-dresden.de> Message-ID: On Sat, 22 Nov 2008, Janis Voigtlaender wrote: > Definitely. And that surfaces even in quite innocently looking programs > and statements about them. The introductory example of the following > technical report may be amusing in that respect: > > http://wwwtcs.inf.tu-dresden.de/~voigt/TUD-FI08-08.pdf In example 1, I don't see on the one hand, why 'takeWhile (null.tail)' could fail with "tail: empty list", since all lists in '[[i] | i <- [1..(div 1 0)]]' are non-empty (namely singletons). On the other hand, aren't those imprecise error problems not just proofs that mixing up errors and exceptions (here treating errors as exceptions) is a bad thing? 'error' is only a candy version of 'undefined' for simplifying debugging. If all 'error's are replaced by 'undefined' (plain bottom) then 'takeWhile p (map h l)' and 'map h (takeWhile (p.h) l)' behave also visually identical, don't they? From nominolo at googlemail.com Sat Nov 22 18:25:06 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Sat Nov 22 18:19:00 2008 Subject: [Haskell-cafe] Extensible Exceptions In-Reply-To: References: <1227313177.3309.6.camel@Congo> <4927609F.5080104@z.odi.ac> <916b84820811220333q7c2605efl76d51cea7d0f3df4@mail.gmail.com> Message-ID: <916b84820811221525y615de18dg7b756ff74ea0bd26@mail.gmail.com> It's a pattern match error, implemented by throwing an asynchronous exception. The idea being, that we only have one mechanism (well, an synchronous exceptions, thrown via throwIO). Yes, I know that there's a difference between "error" and "exception", but I would argue that which is which depends on the program. For example, for most programs a pattern match error is a fatal condition, there's no sane recovery from it. OTOH, in a program like GHCi, a pattern match error in an executed statement is an exceptional condition, which we want to catch, so it doesn't kill GHCi. 2008/11/22 Henning Thielemann : > > On Sat, 22 Nov 2008, Thomas Schilling wrote: > >> Be careful, though. This only works if there's a single constructor >> for your exception type. If there are multiple, you should write it >> like this: >> >> thing_to_try `catch` \(e :: MyErrorType) -> case e of MyError1 _ -> >> ..; MyError2 _ -> ... >> >> If you write `catch` (MyError1 ...) and a MyError2 is thrown, you will >> get a pattern match error exception. > > A "pattern match exception" or "pattern match error"? I mean, not handling a > certain pattern is a programming error not an exceptional condition at > runtime. Thus there is no need to throw a "pattern match exception" which is > catched and handled somewhere else. > > -- Push the envelope. Watch it bend. From lchangying at gmail.com Sat Nov 22 12:46:12 2008 From: lchangying at gmail.com (Changying Li) Date: Sat Nov 22 18:29:11 2008 Subject: [Haskell-cafe] why 'try' not work in parsec Message-ID: <87vdufu00r.fsf@gmail.com> Hi. I read 'write yourself a scheme in 48 hours' and try to modify its code. now part of code is : parseList :: Parser LispVal parseList = liftM List $ sepEndBy parseExpr spaces parseDottedList :: Parser LispVal parseDottedList = do head <- endBy parseExpr spaces tail <- char '.' >> spaces >> parseExpr return $ DottedList head tail parseExpr :: Parser LispVal parseExpr = parseAtom <|> parseString <|> parseNumber <|> parseQuoted <|> do char '(' skipMany space x <- (try parseList) <|> parseDottedList char ')' return x but I got an error when parse (1 . 2): Lisp>>> (1 . 2) Parse error at "lisp" (line 1, column 4): unexpected "." expecting space, letter, "\"", digit, "'", "(" or ")" I think it failed in parseList because when I rewrite 7th line in parseExpr as: x <- (try parseDottedList) <|> parseList it work. so my question is: if it is failed in parseList, why didn't 'try' work? why not the parseExpr try parseDottedList ? -- Thanks & Regards Changying Li From garious at gmail.com Sat Nov 22 19:06:48 2008 From: garious at gmail.com (Greg Fitzgerald) Date: Sat Nov 22 19:00:43 2008 Subject: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL In-Reply-To: <20081122203441.GG17052@scytale.galois.com> References: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> <20081122203441.GG17052@scytale.galois.com> Message-ID: <1f3dc80d0811221606r27503100ofe5c3b31af6da5bd@mail.gmail.com> > $ cabal install OpenGL HOpenGL installs easily with cabal-install, but most HOpenGL examples and tutorials also use GLUT, which is not so painless on Windows. Luckily Conal Elliot just recently posted detailed instructions of how to do it: http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/ -Greg On Sat, Nov 22, 2008 at 12:34 PM, Don Stewart wrote: > ninegua: >> Hi everyone, >> >> It's sad to see the OpenGL binding being dropped from GHC binary >> installers starting from 6.10. Though this issue has been brought up >> and discussed before, I'm sure a lot of people who based their work on >> OpenGL would share the same sympathy. > > $ cabal install OpenGL > >> I'm not here to argue whether this decision by GHC dev team is right >> or wrong, but what's really causing the pain is that the OpenGL >> binding doesn't have its own binary installer for Windows, and >> compilation from source on this platform is non-trivial. I wouldn't >> recommend doing it for ordinary users. > >> So my question is, are we going to see a binary installer for OpenGL >> binding provided separately from either HOpenGL site, or Hackage? Or >> even the GHC installation page? > > This would be a job for the Windows distribution team to sort out. > Each other distro addresses the native packaging problem by developing > packages, and what is needed for a similar team for Windows, to provide > Windows packages. > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jefferson.r.heard at gmail.com Sat Nov 22 19:39:56 2008 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Sat Nov 22 19:33:52 2008 Subject: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL In-Reply-To: <1f3dc80d0811221606r27503100ofe5c3b31af6da5bd@mail.gmail.com> References: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> <20081122203441.GG17052@scytale.galois.com> <1f3dc80d0811221606r27503100ofe5c3b31af6da5bd@mail.gmail.com> Message-ID: <4165d3a70811221639m35fe1cx2a5d5f0fd465cf05@mail.gmail.com> I'm not sure.. can MSVC compiled libraries be intermixed with mingwin libraries? I see Conal has advised installing mingwin as part of his GLUT packaging. -- Jeff On Sat, Nov 22, 2008 at 7:06 PM, Greg Fitzgerald wrote: >> $ cabal install OpenGL > > HOpenGL installs easily with cabal-install, but most HOpenGL examples > and tutorials also use GLUT, which is not so painless on Windows. > Luckily Conal Elliot just recently posted detailed instructions of how > to do it: > > http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/ > > -Greg > > > > On Sat, Nov 22, 2008 at 12:34 PM, Don Stewart wrote: >> ninegua: >>> Hi everyone, >>> >>> It's sad to see the OpenGL binding being dropped from GHC binary >>> installers starting from 6.10. Though this issue has been brought up >>> and discussed before, I'm sure a lot of people who based their work on >>> OpenGL would share the same sympathy. >> >> $ cabal install OpenGL >> >>> I'm not here to argue whether this decision by GHC dev team is right >>> or wrong, but what's really causing the pain is that the OpenGL >>> binding doesn't have its own binary installer for Windows, and >>> compilation from source on this platform is non-trivial. I wouldn't >>> recommend doing it for ordinary users. >> >>> So my question is, are we going to see a binary installer for OpenGL >>> binding provided separately from either HOpenGL site, or Hackage? Or >>> even the GHC installation page? >> >> This would be a job for the Windows distribution team to sort out. >> Each other distro addresses the native packaging problem by developing >> packages, and what is needed for a similar team for Windows, to provide >> Windows packages. >> >> -- Don >> _______________________________________________ >> 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 lemming at henning-thielemann.de Sat Nov 22 19:40:37 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Nov 22 19:34:33 2008 Subject: [Haskell-cafe] Extensible Exceptions In-Reply-To: <916b84820811221525y615de18dg7b756ff74ea0bd26@mail.gmail.com> References: <1227313177.3309.6.camel@Congo> <4927609F.5080104@z.odi.ac> <916b84820811220333q7c2605efl76d51cea7d0f3df4@mail.gmail.com> <916b84820811221525y615de18dg7b756ff74ea0bd26@mail.gmail.com> Message-ID: On Sat, 22 Nov 2008, Thomas Schilling wrote: > It's a pattern match error, implemented by throwing an asynchronous > exception. The idea being, that we only have one mechanism (well, an > synchronous exceptions, thrown via throwIO). > > Yes, I know that there's a difference between "error" and "exception", > but I would argue that which is which depends on the program. For > example, for most programs a pattern match error is a fatal condition, > there's no sane recovery from it. OTOH, in a program like GHCi, a > pattern match error in an executed statement is an exceptional > condition, which we want to catch, so it doesn't kill GHCi. It's completely ok to run something in a sandbox and try to observe errors. But that's debugging and I think there is no need to do this in many places of an application. In general handling errors automatically is not possible, because an error might also be if a program loops infinitely. Thus one should not generally handle an error like an exception. From conal at conal.net Sat Nov 22 19:50:59 2008 From: conal at conal.net (Conal Elliott) Date: Sat Nov 22 19:44:54 2008 Subject: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL In-Reply-To: <1f3dc80d0811221606r27503100ofe5c3b31af6da5bd@mail.gmail.com> References: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> <20081122203441.GG17052@scytale.galois.com> <1f3dc80d0811221606r27503100ofe5c3b31af6da5bd@mail.gmail.com> Message-ID: That post is by David Sankel (camior on #haskell), not by me. My last name has two "t"s. Good luck, - Conal (Elliott) On Sat, Nov 22, 2008 at 4:06 PM, Greg Fitzgerald wrote: > > $ cabal install OpenGL > > HOpenGL installs easily with cabal-install, but most HOpenGL examples > and tutorials also use GLUT, which is not so painless on Windows. > Luckily Conal Elliot just recently posted detailed instructions of how > to do it: > > http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/ > > -Greg > > > > On Sat, Nov 22, 2008 at 12:34 PM, Don Stewart wrote: > > ninegua: > >> Hi everyone, > >> > >> It's sad to see the OpenGL binding being dropped from GHC binary > >> installers starting from 6.10. Though this issue has been brought up > >> and discussed before, I'm sure a lot of people who based their work on > >> OpenGL would share the same sympathy. > > > > $ cabal install OpenGL > > > >> I'm not here to argue whether this decision by GHC dev team is right > >> or wrong, but what's really causing the pain is that the OpenGL > >> binding doesn't have its own binary installer for Windows, and > >> compilation from source on this platform is non-trivial. I wouldn't > >> recommend doing it for ordinary users. > > > >> So my question is, are we going to see a binary installer for OpenGL > >> binding provided separately from either HOpenGL site, or Hackage? Or > >> even the GHC installation page? > > > > This would be a job for the Windows distribution team to sort out. > > Each other distro addresses the native packaging problem by developing > > packages, and what is needed for a similar team for Windows, to provide > > Windows packages. > > > > -- Don > > _______________________________________________ > > 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/20081122/f699cbb0/attachment.htm From duncan.coutts at worc.ox.ac.uk Sat Nov 22 20:07:00 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Nov 22 20:01:00 2008 Subject: [Haskell-cafe] Extensible Exceptions In-Reply-To: References: <1227313177.3309.6.camel@Congo> <4927609F.5080104@z.odi.ac> <916b84820811220333q7c2605efl76d51cea7d0f3df4@mail.gmail.com> <916b84820811221525y615de18dg7b756ff74ea0bd26@mail.gmail.com> Message-ID: <1227402420.7124.260.camel@localhost> On Sun, 2008-11-23 at 01:40 +0100, Henning Thielemann wrote: > On Sat, 22 Nov 2008, Thomas Schilling wrote: > > > It's a pattern match error, implemented by throwing an asynchronous > > exception. The idea being, that we only have one mechanism (well, an > > synchronous exceptions, thrown via throwIO). > > > > Yes, I know that there's a difference between "error" and "exception", > > but I would argue that which is which depends on the program. For > > example, for most programs a pattern match error is a fatal condition, > > there's no sane recovery from it. OTOH, in a program like GHCi, a > > pattern match error in an executed statement is an exceptional > > condition, which we want to catch, so it doesn't kill GHCi. > > It's completely ok to run something in a sandbox and try to observe > errors. But that's debugging and I think there is no need to do this in > many places of an application. In general handling errors automatically is > not possible, because an error might also be if a program loops > infinitely. Thus one should not generally handle an error like an > exception. In general I agree. I would advise against explicitly catching such exceptions just in the region where one is expecting them. That seems like bad design. On the other hand "top level" catch-all handlers that also catch such logic errors sometimes make sense. For example in a Haskell web server where we generate a page dynamically it makes a lot of sense to catch errors in the page-generation function, including pattern match errors, and produce a 500 error code response and log the error message. That's a case, rather like ghci, where some flaw in the program can and should be compartmentalised. There's no attempt to clean up the error but it is a modular system and there is a clear boundary where failures can occur without bringing down the entire system. Duncan From ninegua at gmail.com Sat Nov 22 23:34:55 2008 From: ninegua at gmail.com (Paul L) Date: Sat Nov 22 23:28:51 2008 Subject: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL In-Reply-To: <20081122203441.GG17052@scytale.galois.com> References: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> <20081122203441.GG17052@scytale.galois.com> Message-ID: <856033f20811222034r51c8db57qd76881a8b4ee005b@mail.gmail.com> On 11/22/08, Don Stewart wrote: > ninegua: >> Hi everyone, >> >> It's sad to see the OpenGL binding being dropped from GHC binary >> installers starting from 6.10. Though this issue has been brought up >> and discussed before, I'm sure a lot of people who based their work on >> OpenGL would share the same sympathy. > > $ cabal install OpenGL Nice except that: 1. The command cabal requires cabal-install package to be installed, is it already bundled with all GHC 6.10.1 distributions? 2. It still wouldn't work for the OpenGL package on Windows, because the configure scripts require a Unix-style built environment (MinGW/MinSys or Cygwin). > This would be a job for the Windows distribution team to sort out. > Each other distro addresses the native packaging problem by developing > packages, and what is needed for a similar team for Windows, to provide > Windows packages. Fair enough, a pitty that there is no rpm/emerge/macport equivalent for Windows. -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale From voigt at tcs.inf.tu-dresden.de Sun Nov 23 02:11:53 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Sun Nov 23 02:05:48 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <2f9b2d30811221101k3845cc09w6be8ceae5977c497@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> <7ca3f0160811181246p63ce13adneb920f4ffde06f8c@mail.gmail.com> <2f9b2d30811181951l5e3cd89ejf0ac46d39dfd1bf0@mail.gmail.com> <49280A2C.6070601@tcs.inf.tu-dresden.de> <2f9b2d30811221101k3845cc09w6be8ceae5977c497@mail.gmail.com> Message-ID: <49290239.1030807@tcs.inf.tu-dresden.de> Ryan Ingram wrote: > On Sat, Nov 22, 2008 at 5:33 AM, Janis Voigtlaender > wrote: > >>>You can generally make a persistent data structure with the same >>>asymptotic bounds as the ephemeral structure, ... >> >>I would be very careful with the "generally" here. At least, I am not >>aware that this has been proved to always be possible. > > > Here's an informal proof: > > You can use an intmap to emulate pointers, to turn any ephemeral data > structure into a persistent one. That adds at most a log-n factor to > lookups and updates. For many structures, this is enough to prove > asymptotic bounds equivalence. > > However, the standard 'pointer' model for ephemeral structures makes > the assumption that memory size is limited; otherwise you have to add > a log(n) factor there anyways, both to hold the large pointer values > that get generated and to actually send the bits to the memory bus. > Given this assumption you can take log(memory size) as a constant and > argue that pointer lookup and update via the map is O(1). Ah, that makes sense. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From alexey.skladnoy at gmail.com Sun Nov 23 02:20:47 2008 From: alexey.skladnoy at gmail.com (Alexey Khudyakov) Date: Sun Nov 23 02:14:40 2008 Subject: [Haskell-cafe] How to use Unicode strings? In-Reply-To: <1227381373.7124.239.camel@localhost> References: <53396d9e0811220340o6e6b27eeh4ef80e7f467c7a58@mail.gmail.com> <7ca3f0160811220352o138723fcgadd59b8d6877b6c7@mail.gmail.com> <8425cc0e0811220456i52d9d4bco35ceb81c59ad5236@mail.gmail.com> <20081122180235.GA17052@scytale.galois.com> <1227381373.7124.239.camel@localhost> Message-ID: <8425cc0e0811222320id8ab73cja628dca376de052c@mail.gmail.com> > > This upsets me. We need to get on with doing this properly. The > System.IO.UTF8 module is a useful interim workaround but we're not using > it properly most of the time. > > ... skipped ... > > The right thing to do is to make Prelude.putStrLn do the right thing. We > had a long discussion on how to fix the H98 IO functions to do this > better. We just need to get on with it, or we'll end up with too many > cases of people using System.IO.UTF8 inappropriately. > But this bring question what "the right thing" is? If locale is UTF8 or system support unicode some other way - no problem, just encode string properly. Problem is how to deal with untanslatable characters. Skip? Replace with question marks? Anything other? Probably we need to look how this is solved in other languages. (Or not solved) And this problem related not only to IO. It raises whenever strings cross border between haskell world and outside world. Opening files with unicode names, execing, etc. For example: Prelude> readFile "????" *** Exception: D09;: openFile: does not exist (No such file or directory) Prelude> executeFile "echo" True ["?????? ?????????"] Nothing !59G0A A;><05BAO Althrough it's possible to work around using encodeString/decodeString from Codec.Binary.UTF8.String it won't work on non-UTF8 systems. It's not only neandertalian systems with one-byte locales, windows AFAIK uses other unicode encoding. From dons at galois.com Sun Nov 23 02:36:55 2008 From: dons at galois.com (Don Stewart) Date: Sun Nov 23 02:30:48 2008 Subject: [Haskell-cafe] How to use Unicode strings? In-Reply-To: <8425cc0e0811222320id8ab73cja628dca376de052c@mail.gmail.com> References: <53396d9e0811220340o6e6b27eeh4ef80e7f467c7a58@mail.gmail.com> <7ca3f0160811220352o138723fcgadd59b8d6877b6c7@mail.gmail.com> <8425cc0e0811220456i52d9d4bco35ceb81c59ad5236@mail.gmail.com> <20081122180235.GA17052@scytale.galois.com> <1227381373.7124.239.camel@localhost> <8425cc0e0811222320id8ab73cja628dca376de052c@mail.gmail.com> Message-ID: <20081123073655.GA18740@scytale.galois.com> alexey.skladnoy: > > > > This upsets me. We need to get on with doing this properly. The > > System.IO.UTF8 module is a useful interim workaround but we're not using > > it properly most of the time. > > > > ... skipped ... > > > > The right thing to do is to make Prelude.putStrLn do the right thing. We > > had a long discussion on how to fix the H98 IO functions to do this > > better. We just need to get on with it, or we'll end up with too many > > cases of people using System.IO.UTF8 inappropriately. > > > But this bring question what "the right thing" is? If locale is UTF8 or system > support unicode some other way - no problem, just encode string properly. > Problem is how to deal with untanslatable characters. Skip? Replace with > question marks? Anything other? Probably we need to look how this is > solved in other languages. (Or not solved) > > And this problem related not only to IO. It raises whenever strings cross > border between haskell world and outside world. Opening files with unicode > names, execing, etc. > > For example: > Prelude> readFile "????" > *** Exception: D09;: openFile: does not exist (No such file or directory) > Prelude> executeFile "echo" True ["?????? ?????????"] Nothing > !59G0A A;><05BAO > > Althrough it's possible to work around using encodeString/decodeString from > Codec.Binary.UTF8.String it won't work on non-UTF8 systems. It's not only > neandertalian systems with one-byte locales, windows AFAIK uses other > unicode encoding. For just decoding / encoding in other locales, there are codec libraries. Hunt around on hackage. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/encoding http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Encode -- Don From ryani.spam at gmail.com Sun Nov 23 02:41:38 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sun Nov 23 02:35:34 2008 Subject: [Haskell-cafe] implementing python-style dictionary in Haskell In-Reply-To: <42784f260811221320r5b4dbf58le167cc645f37b73b@mail.gmail.com> References: <90bba1dc0811180237o3163a78dp95df7005c6939c64@mail.gmail.com> <49a77b7a0811180937j7a920450vd542b255c74a3a1f@mail.gmail.com> <7ca3f0160811181246p63ce13adneb920f4ffde06f8c@mail.gmail.com> <2f9b2d30811181951l5e3cd89ejf0ac46d39dfd1bf0@mail.gmail.com> <49280A2C.6070601@tcs.inf.tu-dresden.de> <2f9b2d30811221101k3845cc09w6be8ceae5977c497@mail.gmail.com> <42784f260811221320r5b4dbf58le167cc645f37b73b@mail.gmail.com> Message-ID: <2f9b2d30811222341q7b8638bvf543ca5496d7fd1a@mail.gmail.com> On Sat, Nov 22, 2008 at 1:20 PM, Jason Dusek wrote: > Ryan Ingram wrote: >> ...persistent data structures tend to have much worse constant >> factors and those factors translate to a general 2x-3x >> slowdown. > > Can you explain why that is, or provide a citation for it? > It's not something I've found easy to Google. Consider insertion into a simple binary tree (no balancing condition). The persistent algorithm is: insert :: Key -> Tree -> Tree insert k Tip = Node k Nil Nil insert k (Node k' l r) | k < k' = Node k' (insert k l) r | otherwise = Node k' l (insert k r) The ephemeral algorithm is: insert :: Key -> IORef Tree -> IO () insert k p = do t <- readIORef p case t of Tip -> do l <- newIORef Tip r <- newIORef Tip writeIORef p (Node k l r) Node k' l r -> insert k $ if k < k' then l else r The big difference between these two algorithms is the amount of allocation and copying going on. Both dereference basically the same number of pointers. The ephemeral algorithm allocates exactly one new node and modifies exactly one pointer in memory. The persistent algorithm, on the other hand, copies the entire path being traversed down the tree, allocating that many nodes as well. (All of the "Tip" nodes can be shared; it can be treated like "NULL" in C) Unfortunately, I don't have any references; the 2-3x is an intuitive number from my past experience. It's worse for algorithms where you need to explicitly simulate pointers with maps because the structure is inherently ephemeral, and better for simple structures like the aforementioned binary tree. -- ryan From voigt at tcs.inf.tu-dresden.de Sun Nov 23 02:43:21 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Sun Nov 23 02:37:15 2008 Subject: [Haskell-cafe] Re: Type question in instance of a class In-Reply-To: References: <6cf91caa0811161356o6d56f97fq2edae832eaec3e21@mail.gmail.com> <1115545264.20081117010308@gmail.com> <7ca3f0160811161609t5575ee0fh6f0bfcd574467cef@mail.gmail.com> <49a77b7a0811161620h59501171of1fdc37d2d3f847f@mail.gmail.com> <49280811.7080503@tcs.inf.tu-dresden.de> Message-ID: <49290999.1030104@tcs.inf.tu-dresden.de> Henning Thielemann wrote: > > On Sat, 22 Nov 2008, Janis Voigtlaender wrote: > >> Definitely. And that surfaces even in quite innocently looking programs >> and statements about them. The introductory example of the following >> technical report may be amusing in that respect: >> >> http://wwwtcs.inf.tu-dresden.de/~voigt/TUD-FI08-08.pdf > > > In example 1, I don't see on the one hand, why 'takeWhile (null.tail)' > could fail with "tail: empty list", Because the (GHC) semantics described in the following paper: http://doi.acm.org/10.1145/301631.301637 says so. You can also check it by calculating with the definitions from Section 3 and Figure 8 of the above technical report. Or see it demonstrated on slide pages 32-38 of: http://wwwtcs.inf.tu-dresden.de/~voigt/nwpt2008-slides.pdf > since all lists in '[[i] | i <- > [1..(div 1 0)]]' are non-empty (namely singletons). This does not really have anything to do with the above, but I may just as well say that all lists in '[[i] | i <- [1..(div 1 0)]]' are empty. Or that they are all of length 17. Because there are no lists in '[[i] | i <- [1..(div 1 0)]]'. (Note that the "supply" [1..(div 1 0)] is itself erroneous.) The "tail: empty list" failure mentioned above really has nothing at all to do with the concrete expression '[[i] | i <- [1..(div 1 0)]]'. Any other erroneous expression, such as just 'error "div-by-0"' would lead to the same result. > On the other hand, > aren't those imprecise error problems not just proofs that mixing up > errors and exceptions (here treating errors as exceptions) is a bad > thing? 'error' is only a candy version of 'undefined' for simplifying > debugging. If all 'error's are replaced by 'undefined' (plain bottom) > then 'takeWhile p (map h l)' and 'map h (takeWhile (p.h) l)' behave also > visually identical, don't they? Yes, if all 'error's are replaced by 'undefined', then the two expressions are semantically equivalent. But I don't buy this as a decisive argument in the "errors vs. exceptions" debate. Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From bulat.ziganshin at gmail.com Sun Nov 23 03:36:01 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Nov 23 03:31:08 2008 Subject: [Haskell-cafe] How to use Unicode strings? In-Reply-To: <8425cc0e0811222320id8ab73cja628dca376de052c@mail.gmail.com> References: <53396d9e0811220340o6e6b27eeh4ef80e7f467c7a58@mail.gmail.com> <7ca3f0160811220352o138723fcgadd59b8d6877b6c7@mail.gmail.com> <8425cc0e0811220456i52d9d4bco35ceb81c59ad5236@mail.gmail.com> <20081122180235.GA17052@scytale.galois.com> <1227381373.7124.239.camel@localhost> <8425cc0e0811222320id8ab73cja628dca376de052c@mail.gmail.com> Message-ID: <434042682.20081123113601@gmail.com> Hello Alexey, Sunday, November 23, 2008, 10:20:47 AM, you wrote: > And this problem related not only to IO. It raises whenever strings cross > border between haskell world and outside world. Opening files with unicode > names, execing, etc. this completely depends on libraries, and ghc-bundled i/o libs doesn't support unicode filenames. freearc project contains its own simple i/o library that doesn't have this problem (and also support files >4gb on windows). unfortunately, this library doesn't include any buffering -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Sun Nov 23 04:37:25 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 23 04:31:24 2008 Subject: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL In-Reply-To: <856033f20811222034r51c8db57qd76881a8b4ee005b@mail.gmail.com> References: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> <20081122203441.GG17052@scytale.galois.com> <856033f20811222034r51c8db57qd76881a8b4ee005b@mail.gmail.com> Message-ID: <1227433045.7124.267.camel@localhost> On Sat, 2008-11-22 at 23:34 -0500, Paul L wrote: > On 11/22/08, Don Stewart wrote: > > ninegua: > >> Hi everyone, > >> > >> It's sad to see the OpenGL binding being dropped from GHC binary > >> installers starting from 6.10. Though this issue has been brought up > >> and discussed before, I'm sure a lot of people who based their work on > >> OpenGL would share the same sympathy. > > > > $ cabal install OpenGL > > Nice except that: > > 1. The command cabal requires cabal-install package to be installed, is it > already bundled with all GHC 6.10.1 distributions? It will be bundled in the Haskell platform installer (as will OpenGL). In the mean time here's a binary: http://haskell.org/~duncan/cabal/cabal.exe > 2. It still wouldn't work for the OpenGL package on Windows, because > the configure scripts require a Unix-style built environment > (MinGW/MinSys or Cygwin). Yes, building it requires mingw/msys, but with it cabal install opengl really does work (I've tried it). Duncan From ryani.spam at gmail.com Sun Nov 23 04:47:29 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sun Nov 23 04:41:23 2008 Subject: [Haskell-cafe] why 'try' not work in parsec In-Reply-To: <87vdufu00r.fsf@gmail.com> References: <87vdufu00r.fsf@gmail.com> Message-ID: <2f9b2d30811230147x1c1ccac0i6c2cccefb6d06866@mail.gmail.com> On Sat, Nov 22, 2008 at 9:46 AM, Changying Li wrote: > Hi. > I read 'write yourself a scheme in 48 hours' and try to modify its code. > now part of code is : > > parseList :: Parser LispVal > parseList = liftM List $ sepEndBy parseExpr spaces > <|> do char '(' > skipMany space > x <- (try parseList) <|> parseDottedList > char ')' > return x parseList is succeeding and returning (1); then "char ')'" is failing (because the next character in the input is the '.' -- ryan From claus.reinke at talk21.com Sun Nov 23 07:30:00 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Sun Nov 23 07:24:00 2008 Subject: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL References: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com><20081122203441.GG17052@scytale.galois.com><856033f20811222034r51c8db57qd76881a8b4ee005b@mail.gmail.com> <1227433045.7124.267.camel@localhost> Message-ID: >> >> It's sad to see the OpenGL binding being dropped from GHC binary >> >> installers starting from 6.10. Though this issue has been brought up >> >> and discussed before, I'm sure a lot of people who based their work on >> >> OpenGL would share the same sympathy. >> > >> > $ cabal install OpenGL >> >> Nice except that: >> >> 1. The command cabal requires cabal-install package to be installed, is it >> already bundled with all GHC 6.10.1 distributions? > > It will be bundled in the Haskell platform installer (as will OpenGL). When is that going to be available? It would be nice to know that this unfortunate gap period will end within a few weeks or so, especially since interest in Haskell OpenGL has been picking up again lately. > In the mean time here's a binary: > > http://haskell.org/~duncan/cabal/cabal.exe The last time I tried bootstrapping from that, I didn't get very far, nor have there been any suggestions on what to do about it: http://www.haskell.org/pipermail/cabal-devel/2008-November/004168.html >> 2. It still wouldn't work for the OpenGL package on Windows, because >> the configure scripts require a Unix-style built environment >> (MinGW/MinSys or Cygwin). > > Yes, building it requires mingw/msys, but with it cabal install opengl > really does work (I've tried it). The problem is that this places an additional barrier on distribution: Haskell OpenGL authors cannot simply distribute their Haskell code, because many other Haskellers will not be able to get it to work: if they are on Windows: - they need to install cabal-install (before the cabal.exe, which doesn't seem to be advertized, that involved further dependency recursion http://ghcmutterings.wordpress.com/2008/11/10/bootstrapping-cabal-install/ ) - they need to install MinGW/MSys - then they can do cabal install OpenGL - there still seem to be additional issues with Glut (I haven't got around to trying it since it these things were dropped from extralibs, but the install instructions sound too complicated; patches to support freeglut should go into the glut package, manual copying around shouldn't be needed; but none of that seems to be a cabal issue) A working cabal.exe, easily found from the cabal home page, would be a good start, but several packages suffer from the "needs MinGW/MSys before cabal-install will work" issue. Since there are known-to-work versions of the MinGW/MSys installers, perhaps a cabal package wrapper for these installers could be constructed? - this would make the build dependency explicit, and would allow to record known-to-work versions via cabal dependencies - cabal could check for presence of MinGW/MSys and record the result in its package database - whenever other packages depend on MinGW/MSys, and these cannot be found, cabal could either download and run the installers from the commandline (assuming that is supported), or produce output *with precise instructions, urls, and version numbers* for manual installation (perhaps the preferred option) Then we could simply say "here is the Haskell package, use cabal (url) to build", and windows users would follow the url to download cabal.exe, and cabal.exe would tell them what they need to do to get MinGW/MSys, just as it takes care of other dependencies, and then things would "just work". Claus From ninegua at gmail.com Sun Nov 23 08:00:48 2008 From: ninegua at gmail.com (Paul L) Date: Sun Nov 23 07:54:41 2008 Subject: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL In-Reply-To: <1227433045.7124.267.camel@localhost> References: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> <20081122203441.GG17052@scytale.galois.com> <856033f20811222034r51c8db57qd76881a8b4ee005b@mail.gmail.com> <1227433045.7124.267.camel@localhost> Message-ID: <856033f20811230500w4e1bf1dcj20155b78aeaa9b9d@mail.gmail.com> On 11/23/08, Duncan Coutts wrote: >> 2. It still wouldn't work for the OpenGL package on Windows, because >> the configure scripts require a Unix-style built environment >> (MinGW/MinSys or Cygwin). > > Yes, building it requires mingw/msys, but with it cabal install opengl > really does work (I've tried it). Sure, I don't doubt it. The real trouble is the extra dependency to MinGW/MinSys. I'm reluctant to tell my users to go installing them just for the sake of compiling HOpenGL. Really, OpenGL is the only true cross-platform Graphics solution because it comes as default installation on all platforms. Nothing else comes close to my mind. On a side note, since GHC installation for Windows contains a version of gcc, I wonder how hard it would be to replace the autoconf compilation of HOPenGL with just cabal. Then we'll get rid of the MinGW/MinSys depedency all together. Isn't it the purpose of cabal to replace non-portable build systems (for Haskell at least)? -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale From duncan.coutts at worc.ox.ac.uk Sun Nov 23 08:03:12 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 23 07:57:10 2008 Subject: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL In-Reply-To: References: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> <20081122203441.GG17052@scytale.galois.com> <856033f20811222034r51c8db57qd76881a8b4ee005b@mail.gmail.com> <1227433045.7124.267.camel@localhost> Message-ID: <1227445392.7124.294.camel@localhost> On Sun, 2008-11-23 at 12:30 +0000, Claus Reinke wrote: > >> >> It's sad to see the OpenGL binding being dropped from GHC binary > >> >> installers starting from 6.10. Though this issue has been brought up > >> >> and discussed before, I'm sure a lot of people who based their work on > >> >> OpenGL would share the same sympathy. > >> > > >> > $ cabal install OpenGL > >> > >> Nice except that: > >> > >> 1. The command cabal requires cabal-install package to be installed, is it > >> already bundled with all GHC 6.10.1 distributions? > > > > It will be bundled in the Haskell platform installer (as will OpenGL). > > When is that going to be available? It would be nice to know that > this unfortunate gap period will end within a few weeks or so, especially > since interest in Haskell OpenGL has been picking up again lately. The plan is for the next few weeks. But it'll be done sooner if we can get help, especially from people with access to Windows machines. > > In the mean time here's a binary: > > > > http://haskell.org/~duncan/cabal/cabal.exe > > The last time I tried bootstrapping from that, I didn't get very far, > nor have there been any suggestions on what to do about it: > > http://www.haskell.org/pipermail/cabal-devel/2008-November/004168.html Sorry I missed that email, let me reply now: > The first thing I noticed is that cabal.exe is somewhat stingy about providing > information: there doesn't seem to be a "query" or "info" command and, usually, > the only way to get information is to look at the "-v" output of doing something > (where is the config file? cabal --help should point to it; what are the dependencies > for a given package? we can only ask what cabal --install --dry-run -v is going > to do with the dependencies; where do packages get unpacked temporarily, for > building?..). Querying should be supported, not just doing. Am I missing something? The cabal list command produces things like: $ cabal list opengl * OpenGL Latest version available: 2.2.1.1 Latest version installed: 2.2.1.1 Homepage: http://www.haskell.org/HOpenGL/ Category: Graphics Synopsis: A binding for the OpenGL graphics system License: BSD3 It does not list dependencies. The config file is in $HOME/.cabal/config on unix and under the per-user applications and settings directroy on Windows. This is the path returned by getAppUserDataDirectory "cabal". It's true it doesn't mention this location very often, just the first time you run cabal, when it tells you that it's making a default config file at the given location. Packages get unpacked in a subdirectory of the temp directory. What extra querying would you like? Please file feature requests with the details. > Having found the config file by looking at the -v output of cabal update.., I tried > to enable documentation and to change every path so that cabal would use D: > instead of C: (often crowded). That seemed to work, only that I missed that > installs seem to be global by default, not user (also, build logs still end up on C:)? Yes. People complained when I set the default on windows to be per-user installs. If the windows users can argue it out and come up with a consensus then we can change the defaults again. The location of the build logs should be configurable but currently is not. > (btw, I get lots of warnings about deprecated -ffi) This is very tricky to solve without breaking backwards compatibility for ghc-6.4. > Then I tried cabal install cabal-install (ghc-6.11.20081004, cygwin), and failed. > > 1. cabal.exe prefers network-2.2.0.0 (installed) over network-2.2.0.1, and > building that fails with a Data.Generics issue (wasn't that why the version > number was bumped in the first place? and why is it built when it is installed?) I believe this is now fixed. The ghc-6.10.0.x pre-releases came with a version of network marked as 2.2.0.0 that had different dependencies from the network-2.2.0.0 on hackage. This is what caused cabal-install to think it needed to re-install network. Of course the old version on hackage had not been updated for ghc-6.10 so it failed. > 2. trying cabal install network explicitly does install network.2.2.0.1.. Yes. And I as I understand it, ghc-6.10.1 comes with that version. If not it's a packaging bug. > 3. cabal install cabal-install still fails, see below >From the build log you pasted it looks like something is wrong with your network package. > > Yes, building it requires mingw/msys, but with it cabal install opengl > > really does work (I've tried it). > > The problem is that this places an additional barrier on distribution: > Haskell OpenGL authors cannot simply distribute their Haskell code, > because many other Haskellers will not be able to get it to work: > > if they are on Windows: For the rest of the issues I think the proper solution is the platform installer which would include cabal.exe and a pre-built OpenGL. We could probably do better for packages that need mingw. Most of them record this information in the build-type: Configure, so perhaps cabal.exe should check if sh.exe is present before trying to build packages that need it. If that sounds sensible then lets file a ticket so we don't forget. Duncan From reiner.pope at gmail.com Sun Nov 23 08:07:16 2008 From: reiner.pope at gmail.com (Reiner Pope) Date: Sun Nov 23 08:01:10 2008 Subject: [Haskell-cafe] Fixity parsing, Template Haskell In-Reply-To: References: <4cf038ee0811210459j6d8238c6r73ca3a3932d902cc@mail.gmail.com> <4cf038ee0811220802w1f3040ecl174451f3f26a3a02@mail.gmail.com> Message-ID: <4cf038ee0811230507o258eba62xf7c9b09a3eaa1330@mail.gmail.com> It turns out that there is at least a (partial) solution to my quasiquote problem. Template Haskell's "reify" function can be used to find an operator's fixity, although it seems not for all cases. However, for the purposes of this discussion, suppose I can write a function userFixity :: String -> Q Fixity which takes a operator used in user code and returns its fixity, in the Q monad (Template Haskell's monad). I want this information to be used somehow when creating the Template Haskell AST, so that the operators used have the correct fixities. If I use HSE for parsing Haskell expressions, then I want it to tell me where it unsure of the fixities, so that I can insert the correct ones there. For this use case, I would want HSE to use an AST like I suggested, because it allows the parser to say, "I'm not sure what the correct fixity is". Cheers, Reiner On Sun, Nov 23, 2008 at 8:23 AM, John A. De Goes wrote: > > Though many see it as "losing" information, I agree wholeheartedly with your > proposal to change the AST. > > It's better to have an AST that conveys less information, but truthfully, > than to have an AST that purports to convey more information, when in fact > that information is false. > > In most languages, some things just can't be known at parse time. They need > to be resolved later. > > In this case, the most important thing is following the principle of least > surprise: A Haskell expression inside a quasiquote should work the same as a > Haskell expression outside a quasiquote. > > Violating the "principle of least surprise" is one of the most grievous > mistakes language (and interface) designers make. > > Regards, > > John A. De Goes > N-BRAIN, Inc. > http://www.n-brain.net > [n minds are better than n-1] > > On Nov 22, 2008, at 9:02 AM, Reiner Pope wrote: > >> It seems to me that fixity information behaves more like semantics >> than like syntax. For instance, fixities may be imported, and obey >> namespacing rules. Knowing and correctly handling these rules seems >> beyond the scope of a mere parser: I would hope that a single Haskell >> file could be parsed without reference to any files, and fixity >> declarations seem to be just about the only thing which prevent this >> -- hence my suggestion to change the AST in order to regain this >> property. >> >> The use I envision of it is as I described: writing a quasiquoter >> using HSE to parse the user's Haskell expressions. The problem is >> that, for such a case, HSE (or any other parser) is forced to parse >> infix expressions for which it cannot possibly know the correct >> fixities. Any result with more information than the list form I gave >> would be a lie. >> >> I realise that I don't know how fixities are implemented in Haskell >> compilers, so perhaps I'm misunderstanding how they are treated. >> >> Cheers, >> >> Reiner >> >> On Sat, Nov 22, 2008 at 11:54 PM, Niklas Broberg >> wrote: >>>> >>>> Of course, this would require a change to Template Haskell, so a >>>> second-best solution would be to forbid unparenthesised expressions in >>>> my quasiquoter. Then, parsing can proceed correctly without knowing >>>> the fixities. This would be easiest to do if haskell-src-exts changed >>>> its AST in a similar way to described above for Template Haskell. >>> >>> I'm not sure I follow you here. In what way would it be simpler if HSE >>> changes its AST to a less-information constructor? I won't do that, >>> for the same reason you point out with TH and disadvantages when using >>> it as a library, though I'm still curious what uses you envision and >>> how it would be made easier. I'm still in the process of designing the >>> fixity support for HSE, and all input is valuable. :-) >>> >>> 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 duncan.coutts at worc.ox.ac.uk Sun Nov 23 08:12:12 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 23 08:06:09 2008 Subject: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL In-Reply-To: <856033f20811230500w4e1bf1dcj20155b78aeaa9b9d@mail.gmail.com> References: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> <20081122203441.GG17052@scytale.galois.com> <856033f20811222034r51c8db57qd76881a8b4ee005b@mail.gmail.com> <1227433045.7124.267.camel@localhost> <856033f20811230500w4e1bf1dcj20155b78aeaa9b9d@mail.gmail.com> Message-ID: <1227445932.7124.299.camel@localhost> On Sun, 2008-11-23 at 08:00 -0500, Paul L wrote: > On 11/23/08, Duncan Coutts wrote: > >> 2. It still wouldn't work for the OpenGL package on Windows, because > >> the configure scripts require a Unix-style built environment > >> (MinGW/MinSys or Cygwin). > > > > Yes, building it requires mingw/msys, but with it cabal install opengl > > really does work (I've tried it). > > Sure, I don't doubt it. The real trouble is the extra dependency to > MinGW/MinSys. > I'm reluctant to tell my users to go installing them just for the sake > of compiling HOpenGL. Sure, we're currently in an intermediate situation where the ghc release is smaller but we've not had the first platform release yet. We're only suggesting cabal install opengl on windows for developers, not for your users. > On a side note, since GHC installation for Windows contains a version > of gcc, I wonder how hard it would be to replace the autoconf > compilation of HOPenGL with just cabal. Then we'll get rid of the > MinGW/MinSys depedency all together. Isn't it the purpose of cabal to > replace non-portable build systems (for Haskell at least)? That may well be possible and wherever it is possible we should do it. The MinGW dependency is certainly a pain. Consider this an invitation for anyone to go take a look at the configure scripts for these packages and see how easy they'd be to replace with pure Haskell in the Setup.hs. Duncan From niklas.broberg at gmail.com Sun Nov 23 08:39:21 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Nov 23 08:33:14 2008 Subject: [Haskell-cafe] Fixity parsing, Template Haskell In-Reply-To: <4cf038ee0811230507o258eba62xf7c9b09a3eaa1330@mail.gmail.com> References: <4cf038ee0811210459j6d8238c6r73ca3a3932d902cc@mail.gmail.com> <4cf038ee0811220802w1f3040ecl174451f3f26a3a02@mail.gmail.com> <4cf038ee0811230507o258eba62xf7c9b09a3eaa1330@mail.gmail.com> Message-ID: > On Sun, Nov 23, 2008 at 8:23 AM, John A. De Goes wrote: >> Though many see it as "losing" information, I agree wholeheartedly with your >> proposal to change the AST. >> >> It's better to have an AST that conveys less information, but truthfully, >> than to have an AST that purports to convey more information, when in fact >> that information is false. >> >> In most languages, some things just can't be known at parse time. They need >> to be resolved later. While I agree with you in principle, that the rule of least surprise should be adhered to, I don't agree in this instance. You are assuming that the AST is only used by the parser, and if that was true I would agree with you. But HSE is just as much a library for *building* an AST using combinators. If I changed the AST to one carrying less information, it would be impossible to *ever* get the fixities right in the AST, even for those use cases where the information is known and possible to use. > I want this information to be used somehow when creating the Template > Haskell AST, so that the operators used have the correct fixities. If > I use HSE for parsing Haskell expressions, then I want it to tell me > where it unsure of the fixities, so that I can insert the correct ones > there. For this use case, I would want HSE to use an AST like I > suggested, because it allows the parser to say, "I'm not sure what the > correct fixity is". As noted above, I really don't like that change. If you use HSE for parsing expressions, it would *never* know the correct fixities, and you would always get a completely left-biased tree. Why would that be harder to work with? I understand the argument about least surprise, and that this feature must be strongly documented (which it currently isn't), but for practical purposes I don't see why the current state would be problematic. It should even be trivial to convert the left-biased tree into an intermediate structure exactly like the one you suggest, no? Cheers, /Niklas From jefferson.r.heard at gmail.com Sun Nov 23 09:24:00 2008 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Sun Nov 23 09:17:53 2008 Subject: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL In-Reply-To: <1227445932.7124.299.camel@localhost> References: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> <20081122203441.GG17052@scytale.galois.com> <856033f20811222034r51c8db57qd76881a8b4ee005b@mail.gmail.com> <1227433045.7124.267.camel@localhost> <856033f20811230500w4e1bf1dcj20155b78aeaa9b9d@mail.gmail.com> <1227445932.7124.299.camel@localhost> Message-ID: <4165d3a70811230624u30c12798ycdb87df9b4b01b82@mail.gmail.com> Duncan, what kind of help do you need on the Haskell Platform install? I have access to VMs running windows XP and Vista. On Sun, Nov 23, 2008 at 8:12 AM, Duncan Coutts wrote: > On Sun, 2008-11-23 at 08:00 -0500, Paul L wrote: >> On 11/23/08, Duncan Coutts wrote: >> >> 2. It still wouldn't work for the OpenGL package on Windows, because >> >> the configure scripts require a Unix-style built environment >> >> (MinGW/MinSys or Cygwin). >> > >> > Yes, building it requires mingw/msys, but with it cabal install opengl >> > really does work (I've tried it). >> >> Sure, I don't doubt it. The real trouble is the extra dependency to >> MinGW/MinSys. >> I'm reluctant to tell my users to go installing them just for the sake >> of compiling HOpenGL. > > Sure, we're currently in an intermediate situation where the ghc release > is smaller but we've not had the first platform release yet. > > We're only suggesting cabal install opengl on windows for developers, > not for your users. > >> On a side note, since GHC installation for Windows contains a version >> of gcc, I wonder how hard it would be to replace the autoconf >> compilation of HOPenGL with just cabal. Then we'll get rid of the >> MinGW/MinSys depedency all together. Isn't it the purpose of cabal to >> replace non-portable build systems (for Haskell at least)? > > That may well be possible and wherever it is possible we should do it. > The MinGW dependency is certainly a pain. Consider this an invitation > for anyone to go take a look at the configure scripts for these packages > and see how easy they'd be to replace with pure Haskell in the Setup.hs. > > Duncan > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From lchangying at gmail.com Sun Nov 23 09:52:37 2008 From: lchangying at gmail.com (Changying Li) Date: Sun Nov 23 09:49:12 2008 Subject: [Haskell-cafe] Re: why 'try' not work in parsec References: <87vdufu00r.fsf@gmail.com> <2f9b2d30811230147x1c1ccac0i6c2cccefb6d06866@mail.gmail.com> Message-ID: <87abbqfqa2.fsf@gmail.com> thannks very much!! -- Thanks & Regards Changying Li From duncan.coutts at worc.ox.ac.uk Sun Nov 23 10:12:13 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 23 10:06:11 2008 Subject: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL In-Reply-To: <4165d3a70811230624u30c12798ycdb87df9b4b01b82@mail.gmail.com> References: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> <20081122203441.GG17052@scytale.galois.com> <856033f20811222034r51c8db57qd76881a8b4ee005b@mail.gmail.com> <1227433045.7124.267.camel@localhost> <856033f20811230500w4e1bf1dcj20155b78aeaa9b9d@mail.gmail.com> <1227445932.7124.299.camel@localhost> <4165d3a70811230624u30c12798ycdb87df9b4b01b82@mail.gmail.com> Message-ID: <1227453133.7124.310.camel@localhost> On Sun, 2008-11-23 at 09:24 -0500, Jeff Heard wrote: > Duncan, what kind of help do you need on the Haskell Platform install? > I have access to VMs running windows XP and Vista. The haskell-platform meta-package is here: darcs get http://code.haskell.org/haskell-platform/ This specifies the list of packages and their exact versions. We need to make sure this builds ok on all platforms. So that's the first step. We plan to use the same windows installer builder that ghc uses, but to install a few more packages. The inno setup script is in the ghc tree in distrib/ghc.iss So the second step if you want to help with that is getting the existing ghc installer building ok. We'll start from a binary install image of ghc, then build the non-core libs and add them to the install image. Finally we build the installer. As much as possible we want to automate this and keep the scripts in the haskell-platform repo. Duncan From manlio_perillo at libero.it Sun Nov 23 10:41:08 2008 From: manlio_perillo at libero.it (Manlio Perillo) Date: Sun Nov 23 10:35:35 2008 Subject: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL In-Reply-To: References: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com><20081122203441.GG17052@scytale.galois.com><856033f20811222034r51c8db57qd76881a8b4ee005b@mail.gmail.com> <1227433045.7124.267.camel@localhost> Message-ID: <49297994.4070301@libero.it> Claus Reinke ha scritto: > [...] >>> 2. It still wouldn't work for the OpenGL package on Windows, because >>> the configure scripts require a Unix-style built environment >>> (MinGW/MinSys or Cygwin). >> > [...] > - they need to install MinGW/MSys > - then they can do cabal install OpenGL > Does cabal support precompiled packages? Regards Manlio Perillo From duncan.coutts at worc.ox.ac.uk Sun Nov 23 11:31:06 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 23 11:25:05 2008 Subject: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL In-Reply-To: <49297994.4070301@libero.it> References: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> <20081122203441.GG17052@scytale.galois.com> <856033f20811222034r51c8db57qd76881a8b4ee005b@mail.gmail.com> <1227433045.7124.267.camel@localhost> <49297994.4070301@libero.it> Message-ID: <1227457866.7124.320.camel@localhost> On Sun, 2008-11-23 at 16:41 +0100, Manlio Perillo wrote: > Claus Reinke ha scritto: > > [...] > >>> 2. It still wouldn't work for the OpenGL package on Windows, because > >>> the configure scripts require a Unix-style built environment > >>> (MinGW/MinSys or Cygwin). > >> > > [...] > > - they need to install MinGW/MSys > > - then they can do cabal install OpenGL > > > > > Does cabal support precompiled packages? You can construct a pre-compiled packages from a Cabal package (using an external tool like cabal2rpm). The cabal command line tool has no support for installing such things. Normally one makes native pre-compiled packages like .deb, .rpm, .msi etc and then uses the native system for actually installing them. Duncan From huschi at gmx.org Sun Nov 23 11:43:11 2008 From: huschi at gmx.org (Martin Huschenbett) Date: Sun Nov 23 11:37:04 2008 Subject: [Haskell-cafe] Extensible Exceptions In-Reply-To: <4927609F.5080104@z.odi.ac> References: <1227313177.3309.6.camel@Congo> <4927609F.5080104@z.odi.ac> Message-ID: <4929881F.4010008@gmx.org> BTW, the documentation of catch is bad: the example catch (openFile f ReadMode) (\e -> hPutStr stderr ("Couldn't open "++f++": " ++ show e)) does not type check. Is this a known "bug" or shall I report it anywhere? Regards, Martin. Ross Mellgren schrieb: > I think catch is now basically what catchJust was -- you can just do > > > thing_to_try `catch` (\ (ErrorCall s) -> putStrLn s) > > and it will only catch ErrorCall exceptions. > > -Ross > > > David F. Place wrote: >> Hi, All. >> >> I am trying to understand the new exceptions package in base-4 >> Control.Exceptions. The documentation for catchJust is the same as in >> Control.OldException including this example: >> >> result <- catchJust errorCalls thing_to_try handler >> >> Control.OldException provides the predicate errorCalls, but the new one >> does not. I don't see how to write it. >> >> Thanks for reading. >> >> Cheers, >> David >> >> _______________________________________________ >> 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 cppljevans at suddenlink.net Sun Nov 23 14:24:18 2008 From: cppljevans at suddenlink.net (Larry Evans) Date: Sun Nov 23 14:12:36 2008 Subject: [Haskell-cafe] howto tuple fold to do n-ary cross product? Message-ID: http://www.muitovar.com/monad/moncow.xhtml#list contains a cross function which calculates the cross product of two lists. That attached does the same but then used cross on 3 lists. Naturally, I thought use of fold could generalize that to n lists; however, I'm getting error: {-- cut here Compilation started at Sun Nov 23 13:15:24 make runghc -XMultiParamTypeClasses -XFunctionalDependencies -XFlexibleInstances cross.hs cross.hs:23:30: Occurs check: cannot construct the infinite type: a = (a, a) Expected type: [a] -> [a] -> [a] Inferred type: [a] -> [a] -> [(a, a)] In the first argument of `Data.Foldable.foldl1', namely `cross' In the first argument of `print', namely `(Data.Foldable.foldl1 cross (list2, list3, list1))' make: *** [run] Error 1 }-- cut here How do I apply fold to cross and n lists, for n>=0? TIA. -regards, Larry -------------- next part -------------- A non-text attachment was scrubbed... Name: cross.hs Type: text/x-haskell Size: 479 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081123/49e09d22/cross.bin From lrpalmer at gmail.com Sun Nov 23 14:52:28 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun Nov 23 14:46:22 2008 Subject: [Haskell-cafe] howto tuple fold to do n-ary cross product? In-Reply-To: References: Message-ID: <7ca3f0160811231152o19234e16g9f29677029306a@mail.gmail.com> 2008/11/23 Larry Evans : > http://www.muitovar.com/monad/moncow.xhtml#list > > contains a cross function which calculates the cross product > of two lists. That attached does the same but then > used cross on 3 lists. Naturally, I thought use of > fold could generalize that to n lists; however, > I'm getting error: You should try writing this yourself, it would be a good exercise. To begin with, you can mimic the structure of cross in that tutorial, but make it recursive. After you have a recursive version, you might try switching to fold or foldM. The type of the function will not involve tuples, since they can be arbitrary length (dynamic-length tuples are not supported in Haskell; we use lists for that). cross :: [[a]] -> [[a]] ... Good luck, Luke From greenrd at greenrd.org Sun Nov 23 05:18:48 2008 From: greenrd at greenrd.org (Robin Green) Date: Sun Nov 23 15:32:51 2008 Subject: [Haskell-cafe] Garbage collection as a dual of laziness? Message-ID: <20081123101848.19bf9fc1@greenrd.org> It occurs to me that garbage collection can be seen as some kind of dual of laziness. Laziness means deferring the creation of values until later in the future (or even never). Garbage collection means eagerly destroying data created in the past, and reclaiming the memory used by it, before some other event which would do so (in most garbage-collected languages, I think process destruction is the only other thing that frees memory, leaving aside foreign functions). If you don't have enough laziness (e.g. because of strict pattern matching on tuples) your program might do unnecesssary work (time wastage); if you don't have enough garbage collection (e.g. because a value will never be accessed again but is still referred to from something live), your program might leak memory (space wastage). Of course, space wastage can lead to time wastage, and vice-versa. Can this intuition be made any more formal? Is it merely of pedagogical use, or does anything interesting follow from it? -- Robin From colin at colina.demon.co.uk Sun Nov 23 15:45:41 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Nov 23 15:39:35 2008 Subject: [Haskell-cafe] Garbage collection as a dual of laziness? In-Reply-To: <20081123101848.19bf9fc1@greenrd.org> (Robin Green's message of "Sun\, 23 Nov 2008 10\:18\:48 +0000") References: <20081123101848.19bf9fc1@greenrd.org> Message-ID: >>>>> "Robin" == Robin Green writes: Robin> It occurs to me that garbage collection can be seen as some Robin> kind of dual of laziness. Laziness means deferring the Robin> creation of values until later in the future (or even Robin> never). Garbage collection means eagerly destroying data Robin> created in the past, and reclaiming the memory used by it, Robin> before some other event which would do so I think of garbage collection in the opposite way - that the programmer doesn't free the memory as soon it is known to be safe to do so, but leaves the job to a garbage collector, which may not get round to it for quite some time (perhaps not until program termination, even). -- Colin Adams Preston Lancashire From reiner.pope at gmail.com Sun Nov 23 15:48:14 2008 From: reiner.pope at gmail.com (Reiner Pope) Date: Sun Nov 23 15:42:06 2008 Subject: [Haskell-cafe] Fixity parsing, Template Haskell In-Reply-To: References: <4cf038ee0811210459j6d8238c6r73ca3a3932d902cc@mail.gmail.com> <4cf038ee0811220802w1f3040ecl174451f3f26a3a02@mail.gmail.com> <4cf038ee0811230507o258eba62xf7c9b09a3eaa1330@mail.gmail.com> Message-ID: <4cf038ee0811231248q125890ecpbec58d188855dc8b@mail.gmail.com> On Mon, Nov 24, 2008 at 12:39 AM, Niklas Broberg wrote: >> I want this information to be used somehow when creating the Template >> Haskell AST, so that the operators used have the correct fixities. If >> I use HSE for parsing Haskell expressions, then I want it to tell me >> where it unsure of the fixities, so that I can insert the correct ones >> there. For this use case, I would want HSE to use an AST like I >> suggested, because it allows the parser to say, "I'm not sure what the >> correct fixity is". > > As noted above, I really don't like that change. If you use HSE for > parsing expressions, it would *never* know the correct fixities, and > you would always get a completely left-biased tree. Why would that be > harder to work with? I understand the argument about least surprise, > and that this feature must be strongly documented (which it currently > isn't), but for practical purposes I don't see why the current state > would be problematic. It should even be trivial to convert the > left-biased tree into an intermediate structure exactly like the one > you suggest, no? No, I believe it wouldn't. The left-biased tree cannot distinguish where parentheses have been used from where HSE inserted its own left fixities. For instance, if we have the expressions xs ++ ys ++ zs (xs ++ ys) ++ zs Then HSE will return something like (I'm using strings for the subexpression parses, for simplicity) InfixE (InfixE "xs" "++" "ys") "++" "zs" for both the first and second parses. However, if I then use the knowledge that ++ is right infix, I will want to convert the first, but not the second parses into right infix. I can't do this, because they are both parsed the same way. I would also like to point out that a list representation as I suggested can in fact encode the correct fixities if they are known to HSE. This is true simply because the list constructor is isomorphic to the current constructor in the special case where the list of operators has length 1. For instance, in the first example above, if HSE somehow knew that ++ is right infix, it should return a parse result of InfixE ["xs", InfixE ["ys", "zs"] ["++"]] ["++"] rather than just InfixE ["xs", "ys", "zs"] ["++", "++"] Cheers, Reiner > > Cheers, > > /Niklas > From niklas.broberg at gmail.com Sun Nov 23 16:20:14 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Nov 23 16:14:06 2008 Subject: [Haskell-cafe] Fixity parsing, Template Haskell In-Reply-To: <4cf038ee0811231248q125890ecpbec58d188855dc8b@mail.gmail.com> References: <4cf038ee0811210459j6d8238c6r73ca3a3932d902cc@mail.gmail.com> <4cf038ee0811220802w1f3040ecl174451f3f26a3a02@mail.gmail.com> <4cf038ee0811230507o258eba62xf7c9b09a3eaa1330@mail.gmail.com> <4cf038ee0811231248q125890ecpbec58d188855dc8b@mail.gmail.com> Message-ID: > No, I believe it wouldn't. The left-biased tree cannot distinguish > where parentheses have been used from where HSE inserted its own left > fixities. For instance, if we have the expressions > > xs ++ ys ++ zs > (xs ++ ys) ++ zs > > Then HSE will return something like (I'm using strings for the > subexpression parses, for simplicity) > InfixE (InfixE "xs" "++" "ys") "++" "zs" > for both the first and second parses. However, if I then use the > knowledge that ++ is right infix, I will want to convert the first, > but not the second parses into right infix. I can't do this, because > they are both parsed the same way. No, this is not correct, they are parsed differently. HSE will return (the equivalent of) InfixApp (Paren (InfixApp "xs" "++" "ys")) "++" "zs" for the second case, i.e. with explicit parenthesizing of the subexpression. So they can be and are distinguished, and there would be no problem with the fixity fixing. However... > I would also like to point out that a list representation as I > suggested can in fact encode the correct fixities if they are known to > HSE. This is true simply because the list constructor is isomorphic to > the current constructor in the special case where the list of > operators has length 1. For instance, in the first example above, if > HSE somehow knew that ++ is right infix, it should return a parse > result of > InfixE ["xs", InfixE ["ys", "zs"] ["++"]] ["++"] > rather than just > InfixE ["xs", "ys", "zs"] ["++", "++"] Indeed, I did not realize that. So that means that this representation carries strictly *more* knowledge than that binary constructor, which is of course nice. That certainly makes me somewhat less antagonistic towards a change along these lines. Hmm... Cheers, /Niklas From simon at joyful.com Sun Nov 23 17:46:22 2008 From: simon at joyful.com (Simon Michael) Date: Sun Nov 23 17:40:17 2008 Subject: [Haskell-cafe] ANN: hledger 0.2 released Message-ID: <12E012BA-DCC7-43F3-AC57-D1DE64A0BD30@joyful.com> hledger is a minimal haskell clone of John Wiegley's "ledger" text-based accounting tool (http://newartisans.com/software/ledger.html). hledger generates ledger-compatible register & balance reports from a plain text ledger file, and demonstrates a functional implementation of ledger. For more information, see the hledger home page: http://joyful.com/hledger INSTALLATION ------------ If you have cabal-install, do:: cabal install hledger otherwise, unpack http://hackage.haskell.org/packages/archive/hledger/0.2/hledger-0.2.tar.gz and do:: runhaskell Setup.hs configure runhaskell Setup.hs build sudo runhaskell Setup.hs install (or for the latest code, darcs get http://joyful.com/repos/hledger) NEWS ---- * fixes * fix balance report totals when filtering by account * fix balance report selection of accounts when filtering by account * fix a bug with account name eliding in balance report * if we happen to be showing a not-yet-auto-balanced entry, hide the AUTO marker * fix print command filtering by account * omit transactions with zero amount from register report * Fix bug in parsing of timelogs * rename --showsubs to --subtotal, like ledger * drop --usage flag * don't require quickcheck * features * priced amounts (eg "10h @ $50") and --basis/--cost/-B flag to show them with cost basis * easy --depth option, equivalent to c++ ledger's -d 'l<=N' * smarter y/m/d date parsing for -b and -e (any number of digits, month and day default to 1, separator can be / - or .) * -n flag for balance command * --empty/-E flag * build a library, as well as the exe * new home page url (http://joyful.com/hledger) * publish html and pdf versions of README * detect display preferences for each commodity like c++ ledger * support amounts with multiple currencies/commodities * support --real/-R flag * support -C/--cleared flag to filter by entry status (not transaction status) * support virtual and balanced virtual transactions * parse comment lines beginning with a space, as from M-; in emacs ledger-mode * allow any non-whitespace in account names, perhaps avoiding misleading missing amounts errors * clearer error message when we can't balance an entry * when we fail because of more than one missing amount in an entry, show the full entry * document the built-in test runner in --help * add a --verbose/-v flag, use it to show more test-running detail * includes 43 tests Contributors: * Simon Michael * Tim Docker From bjpop at csse.unimelb.edu.au Sun Nov 23 20:01:22 2008 From: bjpop at csse.unimelb.edu.au (Bernie Pope) Date: Sun Nov 23 19:55:32 2008 Subject: [Haskell-cafe] Garbage collection as a dual of laziness? In-Reply-To: <20081123101848.19bf9fc1@greenrd.org> References: <20081123101848.19bf9fc1@greenrd.org> Message-ID: On 23/11/2008, at 9:18 PM, Robin Green wrote: > It occurs to me that garbage collection can be seen as some kind of > dual of laziness. Laziness means deferring the creation of values > until > later in the future (or even never). A program optimisation might also have the same effect (of avoiding a computation/work). Also note: if you want to take an extreme position, then most (all?) programming languages can be seen to be somewhat "lazy", since computations are goal directed, and therefore functions (or procedures) are only evaluated on points in their domain which are "needed" by the rest of the computation (consider a function defined on an infinite domain). However, that is not the traditional definition of lazy. > Garbage collection means eagerly > destroying data created in the past, and reclaiming the memory used by > it, before some other event which would do so (in most > garbage-collected languages, I think process destruction is the only > other thing that frees memory, leaving aside foreign functions). Don't forget the stack. Besides, I'm not sure how "eager" most GCs are. > If you don't have enough laziness (e.g. because of strict pattern > matching on tuples) your program might do unnecesssary work (time > wastage); if you don't have enough garbage collection (e.g. because a > value will never be accessed again but is still referred to from > something live), your program might leak memory (space wastage). > > Of course, space wastage can lead to time wastage, and vice-versa. > > Can this intuition be made any more formal? Is it merely of > pedagogical use, or does anything interesting follow from it? If you are looking for interesting (and perhaps unconventional) musings on GC, then you might enjoy this paper: "Thermodynamics and Garbage Collection", Henry G Baker. http://home.pipeline.com/~hbaker1/ThermoGC.html Maybe that will spark some new ideas. Cheers, Bernie. From wren at freegeek.org Sun Nov 23 20:32:28 2008 From: wren at freegeek.org (wren ng thornton) Date: Sun Nov 23 20:26:19 2008 Subject: [Haskell-cafe] How to use Unicode strings? In-Reply-To: <8425cc0e0811222320id8ab73cja628dca376de052c@mail.gmail.com> References: <53396d9e0811220340o6e6b27eeh4ef80e7f467c7a58@mail.gmail.com> <7ca3f0160811220352o138723fcgadd59b8d6877b6c7@mail.gmail.com> <8425cc0e0811220456i52d9d4bco35ceb81c59ad5236@mail.gmail.com> <20081122180235.GA17052@scytale.galois.com> <1227381373.7124.239.camel@localhost> <8425cc0e0811222320id8ab73cja628dca376de052c@mail.gmail.com> Message-ID: <492A042C.4060604@freegeek.org> Alexey Khudyakov wrote: > But this bring question what "the right thing" is? If locale is UTF8 or system > support unicode some other way - no problem, just encode string properly. > Problem is how to deal with untanslatable characters. Skip? Replace with > question marks? Anything other? Probably we need to look how this is > solved in other languages. (Or not solved) Regarding untranslatable characters, I think the only correct thing to do is consider it exceptional behavior and have the conversion function accept a handler function which takes the character as input and produces a string for it. That way programs can define their own behavior, since this is something that doesn't have a "right" way to recover in all cases. Canonical handlers which skip, replace with question marks (or other arbitrary character), throw actual exceptions, etc could be provided for convenience. For stream-based "strings" a al ByteString, dealing with this sort of a handler in an efficient manner is fairly straightforward (though some CPS tricks may be needed to get rid of the Maybe in the result of the basic converter). For [Char] strings efficiency is harder, but the implementation should still be easy (given the basic converter). Most extant languages I've seen tend to pick a single solution for all cases, but I don't think we should follow along that path. -- Live well, ~wren From carette at mcmaster.ca Sun Nov 23 23:09:38 2008 From: carette at mcmaster.ca (Jacques Carette) Date: Sun Nov 23 23:04:12 2008 Subject: [Haskell-cafe] Ambiguous type variable woes Message-ID: <492A2902.4000905@mcmaster.ca> I was trying to create a typeclass for an abstract Stack class, and ran into some problems. The following 'works' fine: {-# OPTIONS_GHC -XEmptyDataDecls -XFlexibleContexts -fno-monomorphism-restriction #-} module Stack where data Void class Stack s where push_ :: s a r -> b -> s b (s a r) empty :: s () Void top :: s a (s b r) -> (a, s b r) first :: s a r -> a instance Stack (,) where push_ s a = (a,s) empty = ((),undefined::Void) top = id first = fst p = flip push_ test0 = top . p 2 . p 3 $ empty -- But the following doesn't - I get an "Ambiguous type variable `s' in the contraint `Stack s' arising from the use of `first': test1 = first . p 2 . p 3 $ empty -- sure, that makes sense, it somehow needs to know what flavour of Stack to use even though (or perhaps because) the answer is independent of it. -- So I listen to the "probable fix" and add a type signature: test1 :: Stack (,) => Integer -- This does not however help at all! The only way I have found of 'fixing' this requires annotating the code itself, which I most definitely do not want to do because I specifically want the code to be polymorphic in that way. But GHC 6.8.2 does not want to let me do this. What are my options? Jacques From dons at galois.com Sun Nov 23 23:25:13 2008 From: dons at galois.com (Don Stewart) Date: Sun Nov 23 23:19:02 2008 Subject: [Haskell-cafe] Arch Haskell News: Nov 23 2008 Message-ID: <20081124042513.GA23604@scytale.galois.com> News about Haskell on Arch Linux * Arch now has 734 Haskell packages now * That?s an increase of 29 new packages in the last 8 days! * 3.6 new Haskell releases are occuring each day. Noteworthy, * haskell-hledger-0.2: ?A ledger-compatible text-based accounting tool.? * gitit-0.3.1: ?Wiki using HAppS, git, and pandoc.? * lhc-20081121: ?Lhc Haskell Compiler? * haskell-hosc-0.6: ?Haskell Open Sound Control? * haskell-flickr-0.3.2: ?Haskell binding to the Flickr API? * haskell-delicious-0.3.2: ?Accessing the del.icio.us APIs from Haskell (v2)? * haskell-mediawiki 0.2.3: ?Interfacing with the MediaWiki API? * darcs-2.1.2.2: ?a distributed, interactive, smart revision control system? Full update list, http://archhaskell.wordpress.com/2008/11/24/arch-haskell-news-nov-23-2008/ -- Don From cppljevans at suddenlink.net Sun Nov 23 23:43:42 2008 From: cppljevans at suddenlink.net (Larry Evans) Date: Sun Nov 23 23:31:52 2008 Subject: [Haskell-cafe] Re: howto tuple fold to do n-ary cross product? In-Reply-To: <7ca3f0160811231152o19234e16g9f29677029306a@mail.gmail.com> References: <7ca3f0160811231152o19234e16g9f29677029306a@mail.gmail.com> Message-ID: On 11/23/08 13:52, Luke Palmer wrote: > 2008/11/23 Larry Evans : >> http://www.muitovar.com/monad/moncow.xhtml#list >> >> contains a cross function which calculates the cross product >> of two lists. That attached does the same but then >> used cross on 3 lists. Naturally, I thought use of >> fold could generalize that to n lists; however, >> I'm getting error: > > You should try writing this yourself, it would be a good exercise. To > begin with, you can mimic the structure of cross in that tutorial, but > make it recursive. After you have a recursive version, you might try > switching to fold or foldM. Thanks. The recursive method worked with: -{--cross.hs-- crossr::[[a]] -> [[a]] crossr lls = case lls of { [] -> [] ; [hd] -> map return hd ; hd:tail -> concat (map (\h ->map (\t -> h:t) (crossr tail)) hd) } -}--cross.hs-- However, I'm not sure fold will work because fold (or rather foldr1) from: http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#12 has signature: (a->a->a)->[a]->a and in the cross product case, a is [a1]; so, the signature would be ([a1]->[a1]->[a1]->[[a1]]->[a1] but what's needed as the final result is [[a1]]. Am I missing something? -Larry From sanzhiyan at gmail.com Mon Nov 24 01:40:55 2008 From: sanzhiyan at gmail.com (Andrea Vezzosi) Date: Mon Nov 24 01:34:47 2008 Subject: [Haskell-cafe] Re: howto tuple fold to do n-ary cross product? In-Reply-To: References: <7ca3f0160811231152o19234e16g9f29677029306a@mail.gmail.com> Message-ID: <8625cd9c0811232240s339389f5kd18e21f881589c42@mail.gmail.com> It's more natural to consider the cross product of no sets to be [[]] so your crossr becomes: crossr [] = [[]] crossr (x:xs) = concat (map (\h ->map (\t -> h:t) (crossr tail)) hd) which we can rewrite with list comprehensions for conciseness: crossr [] = [[]] crossr (x:xs) = [ a:as | a <- x, as <- crossr xs ] then look at the definition of foldr: foldr f z [] = z foldr f z (x:xs) = f x (foldr f z xs) and, considering (foldr f z) == crossr, you should derive the definition of f and z. On Mon, Nov 24, 2008 at 5:43 AM, Larry Evans wrote: > On 11/23/08 13:52, Luke Palmer wrote: > >> 2008/11/23 Larry Evans : >> >>> http://www.muitovar.com/monad/moncow.xhtml#list >>> >>> contains a cross function which calculates the cross product >>> of two lists. That attached does the same but then >>> used cross on 3 lists. Naturally, I thought use of >>> fold could generalize that to n lists; however, >>> I'm getting error: >>> >> >> You should try writing this yourself, it would be a good exercise. To >> begin with, you can mimic the structure of cross in that tutorial, but >> make it recursive. After you have a recursive version, you might try >> switching to fold or foldM. >> > > Thanks. The recursive method worked with: > -{--cross.hs-- > crossr::[[a]] -> [[a]] > > crossr lls = case lls of > { [] -> [] > ; [hd] -> map return hd > ; hd:tail -> concat (map (\h ->map (\t -> h:t) (crossr tail)) hd) > } > -}--cross.hs-- > > However, I'm not sure fold will work because fold (or rather foldr1) > from: > http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#12 > > has signature: > > (a->a->a)->[a]->a > > and in the cross product case, a is [a1]; so, the signature would be > > ([a1]->[a1]->[a1]->[[a1]]->[a1] > > but what's needed as the final result is [[a1]]. > > Am I missing something? > > -Larry > > > > _______________________________________________ > 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/20081124/835fa1f8/attachment.htm From sanzhiyan at gmail.com Mon Nov 24 01:44:24 2008 From: sanzhiyan at gmail.com (Andrea Vezzosi) Date: Mon Nov 24 01:38:16 2008 Subject: [Haskell-cafe] Re: howto tuple fold to do n-ary cross product? In-Reply-To: <8625cd9c0811232240s339389f5kd18e21f881589c42@mail.gmail.com> References: <7ca3f0160811231152o19234e16g9f29677029306a@mail.gmail.com> <8625cd9c0811232240s339389f5kd18e21f881589c42@mail.gmail.com> Message-ID: <8625cd9c0811232244m28cbfd33la96c182a29f56709@mail.gmail.com> On Mon, Nov 24, 2008 at 7:40 AM, Andrea Vezzosi wrote: > It's more natural to consider the cross product of no sets to be [[]] so > your crossr becomes: > > crossr [] = [[]] > crossr (x:xs) = concat (map (\h ->map (\t -> h:t) (crossr tail)) hd Ops, hd and tail should be x and xs here. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081124/db41d829/attachment.htm From gleb.alexeev at gmail.com Mon Nov 24 03:09:10 2008 From: gleb.alexeev at gmail.com (Gleb Alexeyev) Date: Mon Nov 24 03:03:10 2008 Subject: [Haskell-cafe] Re: Ambiguous type variable woes In-Reply-To: <492A2902.4000905@mcmaster.ca> References: <492A2902.4000905@mcmaster.ca> Message-ID: Jacques Carette wrote: > -- This does not however help at all! The only way I have found of > 'fixing' this requires annotating the code itself, which I most > definitely do not want to do because I specifically want the code to be > polymorphic in that way. But GHC 6.8.2 does not want to let me do this. > > What are my options? If my guess is correct (sorry if it's not), you want the code to be polymorhic so that you don't have to write the shape of the stack twice. Then the way out is to annotate the type of 'empty': test1 = first . p 2 . p 3 $ (empty :: ((), Void)) From simonpj at microsoft.com Mon Nov 24 04:10:30 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Nov 24 04:04:26 2008 Subject: [Haskell-cafe] RE: [Haskell] GHC 6.10 and OpenGL In-Reply-To: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> References: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3319241A187@EA-EXMSG-C334.europe.corp.microsoft.com> | It's sad to see the OpenGL binding being dropped from GHC binary | installers starting from 6.10. Though this issue has been brought up | and discussed before, I'm sure a lot of people who based their work on | OpenGL would share the same sympathy. The plan (which we have perhaps not articulated as clearly as we should) is this: - We are trying to make the GHC release contain as few libraries as possible - Instead, you get the "batteries" for GHC (ie the libraries) from the Haskell Platform http://www.haskell.org/haskellwiki/Haskell_Platform This lets GHC HQ get out of the library business, and makes it easier to upgrade libraries independently from GHC. But it does mean that GHC without the batteries is a feeble thing. You really want to wait until the HP comes out. The HP will be released in source form, to be installed by cabal-install, of course. But I believe that the intention is that there should be a Windows installer for it too. Things I am less clear about - When will the first HP release compatible with GHC 6.10 appear? - How do users get cabal-install in the first place? Is there a windows installer for it? - Where can one find an up-to-date list of what packages are in HP? - Is there anyone who is actually planning to do the work of making a windows installer for the HP? The HP home page lists only Duncan and Don. I think it'd be good if it was easy to answer these questions from the HP home page. Simon From ods94065 at gmail.com Mon Nov 24 06:12:14 2008 From: ods94065 at gmail.com (Owen Smith) Date: Mon Nov 24 06:06:06 2008 Subject: [Haskell-cafe] Request for code review: slice-1.0.0, TestSupport Message-ID: Hi all, Thanks for your welcome and helpful comments. I've banged out a first attempt at a Haskell library and was curious if anybody would have time or interest in looking it over it for style, design, stuff that's just wrong, or (most likely) stuff that's been done better elsewhere. I'm willing to trade some labor in kind, if there's any odd jobs that can be done by a relative newbie (e.g. maybe setting up a Windows box for OpenGL build testing with GHC 6.10??). The library, slice, is an emulation of Python's list slicing mechanism: http://www.owendsmith.com/slice-1.0.0.tar.gz It uses a triple of Maybes to specify the range, so it's unwieldly in terms of syntax, but the functionality should be there. Mostly, besides gaining experience with writing a library, I wanted to have functionality that skips through a list the way Python slices can, and didn't see a particularly clean way of doing that particular kind of list dicing in Data.List or elsewhere. (In particular, looking towards an application where I'll need to split a list into odd-positioned elements and even-positioned-elements.) I'm doubtful if this is worth publishing as a real package, but maybe someone besides myself will see something in it worth keeping. One thing I did play with was hooking my unit tests into the Cabal build system for my package; if I've read earlier posts correctly this has not been done frequently or systematically, so if that's the case, maybe this can be a contribution towards better testing support. The scripts in the TestSupport module follow a pattern I've used elsewhere in other languages: stomp through the Test directory hierarchy, find all source files that start with Test, and run them on the fly using runhaskell. This works beautifully if you happen to have runhaskell installed and on your system path, but woe to you if you don't--and I'm not sure how to properly capture that as a dependency in Cabal. I'm also wondering if there's any existing Cabal support to configure a proper location for this (I couldn't find it). And if that weren't enough--if similar mechanisms to runhaskell exist for other compilers that I should try to build into this somehow. Thanks! -- O From sanzhiyan at gmail.com Mon Nov 24 06:25:43 2008 From: sanzhiyan at gmail.com (Andrea Vezzosi) Date: Mon Nov 24 06:19:33 2008 Subject: [Haskell-cafe] Ambiguous type variable woes In-Reply-To: <492A2902.4000905@mcmaster.ca> References: <492A2902.4000905@mcmaster.ca> Message-ID: <8625cd9c0811240325g6fcb2e3ex661bd421f6f4a06f@mail.gmail.com> If you want to defer the choice of 's' you've to make it appear in the type signature of test1, so you've to introduce an artificial parameter even if we're interested only in its type. e.g.: data Proxy (s :: * -> * -> *) -- useful because we can't have an argument of type 's' directly, since it's higher-kinded, -- and to document that we're using a phantom argument proxy :: Proxy s proxy = undefined test1 :: Stack s => Proxy s -> Integer test1 pr = first . p 2 . p 3 $ empty `asTypeOf` toStack pr where toStack :: Proxy s -> s a b testTuple = test1 (proxy :: Proxy (,)) enabling LANGUAGE ScopedTypeVars you can rewrite test1 in a more direct fashion: test1 :: forall s. Stack s => Proxy s -> Integer test1 _ = fist . p 2 . p 3 $ (empty :: s () Void) On Mon, Nov 24, 2008 at 5:09 AM, Jacques Carette wrote: > I was trying to create a typeclass for an abstract Stack class, and ran > into some problems. The following 'works' fine: > > {-# OPTIONS_GHC -XEmptyDataDecls -XFlexibleContexts > -fno-monomorphism-restriction #-} > module Stack where > > data Void > > class Stack s where > push_ :: s a r -> b -> s b (s a r) > empty :: s () Void > top :: s a (s b r) -> (a, s b r) > first :: s a r -> a > > instance Stack (,) where > push_ s a = (a,s) > empty = ((),undefined::Void) > top = id > first = fst > > p = flip push_ > test0 = top . p 2 . p 3 $ empty > > -- But the following doesn't - I get an "Ambiguous type variable `s' in the > contraint `Stack s' arising from the use of `first': > test1 = first . p 2 . p 3 $ empty > -- sure, that makes sense, it somehow needs to know what flavour of Stack > to use even though (or perhaps because) the answer is independent of it. > -- So I listen to the "probable fix" and add a type signature: > test1 :: Stack (,) => Integer > > -- This does not however help at all! The only way I have found of > 'fixing' this requires annotating the code itself, which I most definitely > do not want to do because I specifically want the code to be polymorphic in > that way. But GHC 6.8.2 does not want to let me do this. > > What are my options? > > Jacques > _______________________________________________ > 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/20081124/695a1981/attachment.htm From olivier.boudry at gmail.com Mon Nov 24 08:03:37 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Mon Nov 24 07:57:28 2008 Subject: [Haskell-cafe] Problem getting code from AFP08 parallel tutorial to run in parallel Message-ID: Hi all, I'm reading the following tutorial: http://research.microsoft.com/~simonpj/papers/parallel/AFP08-notes.pdf "A Tutorial on Parallel and Concurrent Programming in Haskell" and have problems getting the expected speed improvement from running two tasks in parallel. With any version of the code present in pages 1-7 of the tutorial I keep getting the CPU stick to 50%. I did not forget to compile the code with `-threaded` and run it with `+RTS -N2` and it runs on a dual core machine on which I already used the Control.Parallel.Strategies.parMap function and got 100% CPU usage. The first version of the parallel function in the tutorial (page 6) is: parSumFibEuler :: Int ?> Int ?> Int parSumFibEuler a b = f 'par' (f + e) where f = fib a e = sumEuler b In the tutorial, swapping f and e on the 3rd line does the job, but in my case it doesn't change anything. C:\Temp\haskell>ghc --make -threaded SumEulerP6.hs [1 of 1] Compiling Main ( SumEulerP6.hs, SumEulerP6.o ) Linking SumEulerP6.exe ... C:\Temp\haskell>SumEulerP6 +RTS -N1 sum: 119201850 time: 36.890625 seconds C:\Temp\haskell>SumEulerP6 +RTS -N2 sum: 119201850 time: 36.859375 seconds Next page of the tutorial the tasks are explicitly sequenced so the code does not depend on the ordering of the two `+` operands: parSumFibEuler :: Int -> Int -> Int parSumFibEuler a b = f `par` (e `pseq` (f + e)) where f = fib a e = sumEuler b With once again a disappointing result: C:\Temp\haskell>ghc --make -threaded SumEulerP7.hs [1 of 1] Compiling Main ( SumEulerP7.hs, SumEulerP7.o ) Linking SumEulerP7.exe ... C:\Temp\haskell>SumEulerP7 +RTS -N1 sum: 119201850 time: 36.875 seconds C:\Temp\haskell>SumEulerP7 +RTS -N2 sum: 119201850 time: 36.75 seconds I tried this on a Windows XP Dell Dual Core with GHC 6.10.1 and on a iMac Dual Core with GHC 6.8.3 and got the same result on both. I'm probably missing something really stupid but I'm lacking the "parallel thinking" skills to understand how to look at the problem and resolve it. Any pointers? Thanks, Olivier. From cppljevans at suddenlink.net Mon Nov 24 08:23:22 2008 From: cppljevans at suddenlink.net (Larry Evans) Date: Mon Nov 24 08:11:36 2008 Subject: [Haskell-cafe] Re: howto tuple fold to do n-ary cross product? In-Reply-To: <8625cd9c0811232240s339389f5kd18e21f881589c42@mail.gmail.com> References: <7ca3f0160811231152o19234e16g9f29677029306a@mail.gmail.com> <8625cd9c0811232240s339389f5kd18e21f881589c42@mail.gmail.com> Message-ID: On 11/24/08 00:40, Andrea Vezzosi wrote: > It's more natural to consider the cross product of no sets to be [[]] so > your crossr becomes: > > crossr [] = [[]] > crossr (x:xs) = concat (map (\h ->map (\t -> h:t) (crossr tail)) hd) > > which we can rewrite with list comprehensions for conciseness: > > crossr [] = [[]] > crossr (x:xs) = [ a:as | a <- x, as <- crossr xs ] > > then look at the definition of foldr: > foldr f z [] = z > foldr f z (x:xs) = f x (foldr f z xs) > > and, considering (foldr f z) == crossr, you should derive the definition > of f and z. THANK YOU Andrea (and Luke) for prompting me to a solution: crossf::[[a]] -> [[a]] crossf lls = foldr (\hd tail -> concat (map (\h ->map (\t -> h:t) tail) hd)) [[]] lls The reason I'm interested in this is that the cross product problem came up in the boost newsgroup: http://thread.gmane.org/gmane.comp.lib.boost.devel/182797/focus=182915 I believe programming the solution in a truly functional language might help a boost mpl programmer to see a solution in mpl. I expect there's some counterpart to haskell's map, concat, and foldr in mpl and so the mpl solution would be similar to the above crossf solution. -kind regards to both of you, Larry From tphyahoo at gmail.com Mon Nov 24 09:16:16 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Mon Nov 24 09:10:20 2008 Subject: [Haskell-cafe] Re: cabal install HaXml installs wrong version unless I specify the version number In-Reply-To: <1226756358.15832.25.camel@localhost> References: <910ddf450811150302s3f8583baxe561a50856e2a337@mail.gmail.com> <910ddf450811150339u7920683do227dceb02383634f@mail.gmail.com> <1226750578.15832.12.camel@localhost> <910ddf450811150431ve395cb2gd9ade01e9d8c6a6a@mail.gmail.com> <1226756358.15832.25.camel@localhost> Message-ID: <910ddf450811240616h676d90bta5798671185ff01b@mail.gmail.com> I have run into another issue with cabal packaging, which seems related to the issues discussed above. (see attached tar file for complete example of failure scenario) If I have a cabal package that depends on two other packages -- package xml-parsec requires HaXml == 1.19.4 (the latest) -- package HAppS-Server requires HaXml == 1.13.3 (the default) ghc --make testDepConflict.hs works fine. But I can't install via cabal without, I guess, breaking out the conflict into a separate cabal package. Build-Depends: HAppS-Server, xml-parsec, HaXml -- (Uses HaXml 1.13.3, the default HaXml if no version number is specified) -- Cabal says: ---- Could not find module `Text.XML.HaXml.Posn': ---- it is a member of package HaXml-1.19.4, which is hidden -- I say: ---- Ok, I understand why this doesn't work. Build-Depends: HAppS-Server xml-parsec, HaXml == 1.19.4 -- Cabal says: ---- cabal: dependencies conflict: HAppS-Server requires HaXml ==1.13.3 however ---- HaXml-1.13.3 was excluded because CabalDepConflict-0.1 requires HaXml ==1.19.4 -- I say: ---- Since HAppS-Server is its own separate package, why is this a conflict? ---- Shouldn't this work? The workaround is to put the bits of the current package that depend on HaXml 1.19.4 into their own separate package, which doesn't require HAppS-Server. But shouldn't it be possible for cabal to figure out how to install the package without doing this? 2008/11/15 Duncan Coutts : > On Sat, 2008-11-15 at 13:31 +0100, Thomas Hartman wrote: >> This is all news to me, and un-googleable to boot: >> >> http://www.google.pl/search?hl=en&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=cabal+referred-versions&spell=1 >> >> (no results) > > It finds something for me (with the right spelling of preferred), eg > this thread from the libraries list: > > http://archive.netbsd.se/?ml=haskell-libraries&a=2008-10&t=8748731 > >> So yes, I think this referred-versions machinery should at least be >> made more transparent for situations when it does the wrong thing, >> like with xml-parsec. > > Sure, though it is worth remembering that doing the right thing for > xml-parsec is completely a guessing game since the package does not say > which version it needs and yet works with some versions and not others. > That is the root of this problem. We should be thinking about ways to > persuade package authors (or others) to supply the correct information. > > That's where the package versioning policy comes in. > >> I think your last suggestion is good >> >> > cabal install haxml >> > Downloading HaXml-1.13.3... >> > Note: the recommended version is HaXml-1.13.3 but latest version is >> > HaXml-1.19, use cabal install haxml-1.19 if you want that version. >> >> I would have this message pop up for both cabal install and cabal >> upgrade -- especiallly since with cabal upgrade the result was for me >> completely bafflling. > > Ok, so that we do not forget this, would you mind filing a ticket to > explain the confusion and the suggested solution. Linking to this thread > would also help. > > http://hackage.haskell.org/trac/hackage/ > > > Duncan > > -------------- next part -------------- A non-text attachment was scrubbed... Name: CabalDepConflict.tar.gz Type: application/x-gzip Size: 1964582 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081124/08597395/CabalDepConflict.tar-0001.bin From dokondr at gmail.com Mon Nov 24 11:29:35 2008 From: dokondr at gmail.com (Dmitri O.Kondratiev) Date: Mon Nov 24 11:23:26 2008 Subject: [Haskell-cafe] SOEGraphics in GHC? Message-ID: <53396d9e0811240829h617b1a6waf914aa4f608a3ae@mail.gmail.com> Please help, to locate in GHC distribution SOEGraphics library from Paul Hudak, book "The Haskell School of Expression" (http://www.haskell.org/soe/ ) Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081124/3245c0e3/attachment.htm From apfelmus at quantentunnel.de Mon Nov 24 11:37:40 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Mon Nov 24 11:31:39 2008 Subject: [Haskell-cafe] Re: howto tuple fold to do n-ary cross product? In-Reply-To: <7ca3f0160811231152o19234e16g9f29677029306a@mail.gmail.com> References: <7ca3f0160811231152o19234e16g9f29677029306a@mail.gmail.com> Message-ID: Luke Palmer wrote: > Larry Evans wrote: >> >> contains a cross function which calculates the cross product >> of two lists. That attached does the same but then >> used cross on 3 lists. Naturally, I thought use of >> fold could generalize that to n lists; however, >> I'm getting error: > > The type of the function will not involve tuples, since they can be > arbitrary length (dynamic-length tuples are not supported in Haskell; > we use lists for that). > > cross :: [[a]] -> [[a]] > > .... This is the sequence function from Control.Monad. cross :: [[a]] -> [[a]] cross = sequence > cross [[1,2],[3,4]] [[1,3],[1,4],[2,3],[2,4]] Regards, apfelmus From leimy2k at gmail.com Mon Nov 24 13:23:47 2008 From: leimy2k at gmail.com (David Leimbach) Date: Mon Nov 24 13:17:36 2008 Subject: [Haskell-cafe] SOEGraphics in GHC? In-Reply-To: <53396d9e0811240829h617b1a6waf914aa4f608a3ae@mail.gmail.com> References: <53396d9e0811240829h617b1a6waf914aa4f608a3ae@mail.gmail.com> Message-ID: <3e1162e60811241023g116da1dfhb6cc76adea42bd11@mail.gmail.com> Did you try clicking the links on that page you referenced? There's one labelled software. http://www.haskell.org/soe/software1.htm Which shows source code links for SOE. Dave 2008/11/24 Dmitri O.Kondratiev > Please help, to locate in GHC distribution SOEGraphics library from > Paul Hudak, book "The Haskell School of Expression" > (http://www.haskell.org/soe/ ) > > Thanks! > > _______________________________________________ > 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/20081124/445270cd/attachment.htm From dons at galois.com Mon Nov 24 13:51:40 2008 From: dons at galois.com (Don Stewart) Date: Mon Nov 24 13:45:27 2008 Subject: [Haskell-cafe] Problem getting code from AFP08 parallel tutorial to run in parallel In-Reply-To: References: Message-ID: <20081124185140.GC7952@scytale.galois.com> Which version of GHC are you using? This particular example triggers a "boundary condition" in ghc 6.10 where, with only one spark, GHC doesn't fire up the extra cpu. Try it with 6.8.x to see that in action. Simon Marlow may be able to comment more. -- Don olivier.boudry: > Hi all, > > I'm reading the following tutorial: > http://research.microsoft.com/~simonpj/papers/parallel/AFP08-notes.pdf > "A Tutorial on Parallel and Concurrent > Programming in Haskell" and have problems getting the expected speed > improvement from running two tasks in parallel. With any version of > the code present in pages 1-7 of the tutorial I keep getting the CPU > stick to 50%. > > I did not forget to compile the code with `-threaded` and run it with > `+RTS -N2` and it runs on a dual core machine on which I already used > the Control.Parallel.Strategies.parMap function and got 100% CPU > usage. > > The first version of the parallel function in the tutorial (page 6) is: > > parSumFibEuler :: Int ?> Int ?> Int > parSumFibEuler a b > = f 'par' (f + e) > where > f = fib a > e = sumEuler b > > In the tutorial, swapping f and e on the 3rd line does the job, but in > my case it doesn't change anything. > > C:\Temp\haskell>ghc --make -threaded SumEulerP6.hs > [1 of 1] Compiling Main ( SumEulerP6.hs, SumEulerP6.o ) > Linking SumEulerP6.exe ... > > C:\Temp\haskell>SumEulerP6 +RTS -N1 > sum: 119201850 > time: 36.890625 seconds > > C:\Temp\haskell>SumEulerP6 +RTS -N2 > sum: 119201850 > time: 36.859375 seconds > > Next page of the tutorial the tasks are explicitly sequenced so the > code does not depend on the ordering of the two `+` operands: > > parSumFibEuler :: Int -> Int -> Int > parSumFibEuler a b > = f `par` (e `pseq` (f + e)) > where > f = fib a > e = sumEuler b > > With once again a disappointing result: > > C:\Temp\haskell>ghc --make -threaded SumEulerP7.hs > [1 of 1] Compiling Main ( SumEulerP7.hs, SumEulerP7.o ) > Linking SumEulerP7.exe ... > > C:\Temp\haskell>SumEulerP7 +RTS -N1 > sum: 119201850 > time: 36.875 seconds > > C:\Temp\haskell>SumEulerP7 +RTS -N2 > sum: 119201850 > time: 36.75 seconds > > I tried this on a Windows XP Dell Dual Core with GHC 6.10.1 and on a > iMac Dual Core with GHC 6.8.3 and got the same result on both. I'm > probably missing something really stupid but I'm lacking the "parallel > thinking" skills to understand how to look at the problem and resolve > it. > > Any pointers? > > Thanks, > > Olivier. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From dons at galois.com Mon Nov 24 14:38:05 2008 From: dons at galois.com (Don Stewart) Date: Mon Nov 24 14:31:54 2008 Subject: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C3319241A187@EA-EXMSG-C334.europe.corp.microsoft.com> References: <856033f20811221231n6cfdb3ew46835f9636ceed68@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3319241A187@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20081124193805.GC8635@scytale.galois.com> simonpj: > > | It's sad to see the OpenGL binding being dropped from GHC binary > | installers starting from 6.10. Though this issue has been brought up > | and discussed before, I'm sure a lot of people who based their work on > | OpenGL would share the same sympathy. > > The plan (which we have perhaps not articulated as clearly as we should) is this: > > - We are trying to make the GHC release contain as few libraries as possible > - Instead, you get the "batteries" for GHC (ie the libraries) from the Haskell Platform > http://www.haskell.org/haskellwiki/Haskell_Platform > > This lets GHC HQ get out of the library business, and makes it easier to upgrade libraries independently from GHC. But it does mean that GHC without the batteries is a feeble thing. You really want to wait until the HP comes out. > > The HP will be released in source form, to be installed by cabal-install, of course. But I believe that the intention is that there should be a Windows installer for it too. > > Things I am less clear about > - When will the first HP release compatible with GHC 6.10 appear? Next few weeks. > - How do users get cabal-install in the first place? Is there > a windows installer for it? Via binaries for their platform (e.g. windows .exe's). > - Where can one find an up-to-date list of what packages are in HP? The definitive version, http://code.haskell.org/haskell-platform/haskell-platform.cabal There's also a bug tracker. > - Is there anyone who is actually planning to do the work of making > a windows installer for the HP? The HP home page lists only > Duncan and Don. We need a Windows platform champion, as we do for other distros, who's in the business of making native packages for that key system. Neil? > I think it'd be good if it was easy to answer these questions from the HP home page. > Yes! -- Don From skynare at gmail.com Mon Nov 24 14:40:26 2008 From: skynare at gmail.com (sam lee) Date: Mon Nov 24 14:34:16 2008 Subject: [Haskell-cafe] SOEGraphics in GHC? In-Reply-To: <53396d9e0811240829h617b1a6waf914aa4f608a3ae@mail.gmail.com> References: <53396d9e0811240829h617b1a6waf914aa4f608a3ae@mail.gmail.com> Message-ID: <4e7aa0f80811241140m580b21fflb5246c859b49f733@mail.gmail.com> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HGL or http://hackage.haskell.org/cgi-bin/hackage-scripts/package/soegtk 2008/11/24 Dmitri O.Kondratiev : > Please help, to locate in GHC distribution SOEGraphics library from > Paul Hudak, book "The Haskell School of Expression" > (http://www.haskell.org/soe/ ) > > Thanks! > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From lgreg.meredith at biosimilarity.com Mon Nov 24 17:06:33 2008 From: lgreg.meredith at biosimilarity.com (Greg Meredith) Date: Mon Nov 24 17:00:23 2008 Subject: [Haskell-cafe] monads with take-out options Message-ID: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com> Haskellians, Some monads come with take-out options, e.g. - List - Set In the sense that if unit : A -> List A is given by unit a = [a], then taking the head of a list can be used to retrieve values from inside the monad. Some monads do not come with take-out options, IO being a notorious example. Some monads, like Maybe, sit on the fence about take-out. They'll provide it when it's available. Now, are there references for a theory of monads and take-out options? For example, it seems that all sensible notions of containers have take-out. Can we make the leap and define a container as a monad with a notion of take-out? Has this been done? Are there reasons for not doing? Can we say what conditions are necessary to ensure a notion of take-out? 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/20081124/d29eb65c/attachment.htm From dagit at codersbase.com Mon Nov 24 17:27:26 2008 From: dagit at codersbase.com (Jason Dagit) Date: Mon Nov 24 17:21:15 2008 Subject: [Haskell-cafe] monads with take-out options In-Reply-To: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com> References: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com> Message-ID: 2008/11/24 Greg Meredith > Haskellians, > Some monads come with take-out options, e.g. > > - List > - Set > > In the sense that if unit : A -> List A is given by unit a = [a], then > taking the head of a list can be used to retrieve values from inside the > monad. > > Some monads do not come with take-out options, IO being a notorious > example. > I think the take-out option for IO is usually called 'main'. :) Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081124/27518e64/attachment.htm From jonathanccast at fastmail.fm Mon Nov 24 17:30:03 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Nov 24 17:23:55 2008 Subject: [Haskell-cafe] monads with take-out options In-Reply-To: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com> References: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com> Message-ID: <1227565803.31351.13.camel@jcchost> On Mon, 2008-11-24 at 14:06 -0800, Greg Meredith wrote: > Haskellians, > Some monads come with take-out options, e.g. > * List > * Set > In the sense that if unit : A -> List A is given by unit a = [a], then > taking the head of a list can be used to retrieve values from inside > the monad. > Some monads do not come with take-out options, IO being a notorious > example. > Some monads, like Maybe, sit on the fence about take-out. They'll > provide it when it's available. It might be pointed out that List and Set are also in this region. In fact, Maybe is better, in this regard, since you know, if fromJust succeeds, that it will only have once value to return. head might find one value to return, no values, or even multiple values. A better example of a monad that always has a left inverse to return is ((,) w), where w is a monoid. In this case, snd . return = id :: a -> a as desired (we always have the left inverses join . return = id :: m a -> m a where join a = a >>= id). > Now, are there references for a theory of monads and take-out options? > For example, it seems that all sensible notions of containers have > take-out. Sounds reasonable. Foldable gives you something: foldr const undefined will pull out the last value visited by foldr, and agrees with head at []. > Can we make the leap and define a container as a monad with a notion > of take-out? If you want. I'd rather define a container to be Traversable; it doesn't exclude anything interesting (that I'm aware of), and is mostly more powerful. > Has this been done? Are you familiar at all with Foldable (http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html#t%3AFoldable) and Traversable (http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html#t%3ATraversable) jcc From john at repetae.net Mon Nov 24 17:50:22 2008 From: john at repetae.net (John Meacham) Date: Mon Nov 24 17:44:10 2008 Subject: [Haskell-cafe] Garbage collection as a dual of laziness? In-Reply-To: <20081123101848.19bf9fc1@greenrd.org> References: <20081123101848.19bf9fc1@greenrd.org> Message-ID: <20081124225022.GD32430@sliver.repetae.net> A way this analogy breaks down is that lazyness evaluates precisely what is needed, and no more. The set of values evaluated by lazyness is exactly equivalent to the set of values needed. Garbage collectors are conservative by nature, the values collected by the garbage collector are some subset of the values that will not be needed in the future, which particular subset that is depends on details of the garbage collector and the optimizer. Also, there is no real direct way to "observe" _when_ values have been garbage collected (without resorting to weak pointers or implementation details) so it is questionable what a correspondence will give you practically in terms of reasoning ability. Whether the garbage was 'collected' right away or when needed, as long as you don't run out of memory the program is oblivious to it. John -- John Meacham - ?repetae.net?john? From bartek at sudety.it Mon Nov 24 18:56:27 2008 From: bartek at sudety.it (Bartosz =?iso-8859-1?q?W=F3jcik?=) Date: Mon Nov 24 17:50:21 2008 Subject: [Haskell-cafe] Windows vs. Linux x64 Message-ID: <200811250056.27632.bartek@sudety.it> Hi Everybody, while working on my resent project I've noticed that my code seems to be faster under Windows than under Linux x64. More exactly this was an AI game evaluator that ran on given parameters. There was no IO performed. I've run 3 lots of test on both systems and stored some figures. It was physicaly the same PC. 1st lot WinXP total time = 27.18 secs (1359 ticks @ 20 ms) total alloc = 5,788,242,604 bytes (excludes profiling overheads) Linux total time = 34.44 secs (1722 ticks @ 20 ms) total alloc = 11,897,757,176 bytes (excludes profiling overheads) 2nd lot WinXP total time = 63.96 secs (3198 ticks @ 20 ms) total alloc = 13,205,507,148 bytes (excludes profiling overheads) Linux total time = 80.76 secs (4038 ticks @ 20 ms) total alloc = 27,258,694,888 bytes (excludes profiling overheads) 3rd lot WinXP total time = 207.10 secs (10355 ticks @ 20 ms) total alloc = 44,982,716,780 bytes (excludes profiling overheads) Linux total time = 267.58 secs (13379 ticks @ 20 ms) total alloc = 92,307,482,416 bytes (excludes profiling overheads) I've used the same compile and runtime options for both. I've tried to run with -H option, but this didn't improve anything. Is this common behaviour? Does anybody know what can be the reason? regards, Bartek From dons at galois.com Mon Nov 24 17:59:02 2008 From: dons at galois.com (Don Stewart) Date: Mon Nov 24 17:52:51 2008 Subject: [Haskell-cafe] Windows vs. Linux x64 In-Reply-To: <200811250056.27632.bartek@sudety.it> References: <200811250056.27632.bartek@sudety.it> Message-ID: <20081124225902.GG10286@scytale.galois.com> bartek: > Hi Everybody, > > while working on my resent project I've noticed that my code seems to be > faster under Windows than under Linux x64. > More exactly this was an AI game evaluator that ran on given parameters. There > was no IO performed. I've run 3 lots of test on both systems and stored some > figures. It was physicaly the same PC. > > 1st lot > WinXP > total time = 27.18 secs (1359 ticks @ 20 ms) > total alloc = 5,788,242,604 bytes (excludes profiling overheads) > Linux > total time = 34.44 secs (1722 ticks @ 20 ms) > total alloc = 11,897,757,176 bytes (excludes profiling overheads) > > 2nd lot > WinXP > total time = 63.96 secs (3198 ticks @ 20 ms) > total alloc = 13,205,507,148 bytes (excludes profiling overheads) > Linux > total time = 80.76 secs (4038 ticks @ 20 ms) > total alloc = 27,258,694,888 bytes (excludes profiling overheads) > > 3rd lot > WinXP > total time = 207.10 secs (10355 ticks @ 20 ms) > total alloc = 44,982,716,780 bytes (excludes profiling overheads) > Linux > total time = 267.58 secs (13379 ticks @ 20 ms) > total alloc = 92,307,482,416 bytes (excludes profiling overheads) > > I've used the same compile and runtime options for both. I've tried to run > with -H option, but this didn't improve anything. > Is this common behaviour? Does anybody know what can be the reason? Is Windows running in 32 bit? What gcc versions are you using on each system? -- Don From lgreg.meredith at biosimilarity.com Mon Nov 24 18:06:34 2008 From: lgreg.meredith at biosimilarity.com (Greg Meredith) Date: Mon Nov 24 18:00:23 2008 Subject: [Haskell-cafe] monads with take-out options In-Reply-To: <1227565803.31351.13.camel@jcchost> References: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com> <1227565803.31351.13.camel@jcchost> Message-ID: <5de3f5ca0811241506l66500d0bu8fb803c1e6ceba84@mail.gmail.com> Jonathan, Nice! Thanks. In addition to implementations, do we have more mathematical accounts? Let me expose more of my motives. - i am interested in a first-principles notion of data. Neither lambda nor ?-calculus come with a criterion for determining which terms represent data and which programs. You can shoe-horn in such notions -- and it is clear that practical programming relies on such a separation -- but along come nice abstractions like generic programming and the boundary starts moving again. (Note, also that one of the reasons i mention ?-calculus is because when you start shipping data between processes you'd like to know that this term really is data and not some nasty little program...) One step towards a first-principles characterization of data (as separate from program) is a first-principles characterization of containers. - Along these lines Barry Jay's pattern-matching calculus is an intriguing step towards such a characterization. This also links up with Foldable and Traversable. - i also looked at variants of Wischik's fusion calculus in which Abramsky's proof expressions characterize the notion of shippable data. (Part of the intuition here is that shippable data really ought to have a terminating access property for access to some interior region. The linear types for proof expressions guarantee such a property for all well-typed terms.) - There is a real tension between nominal strategies and structural strategies for accessing data. This is very stark when one starts adding notions of data to the ?-calculus -- which is entirely nominal in characterization. Moreover, accessing some piece of data by path is natural, obvious and programmatically extensible. Accessing something by name is fast. These two ideas come together if one's nominal technology (think Gabbay-Pitt's freshness widgetry) comes with a notion of names that have structure.* - Finally, i think the notion of take-out option has something to do with being able to demarcate regions. In this sense i think there is a very deep connection with Oleg's investigations of delimited continuations and -- forgive the leap -- Linda tuple spaces. As i've tried to indicate, in much the same way that monad is a very, very general abstraction, i believe that there are suitably general abstractions that account for a broad range of phenomena and still usefully separate a notion of data from a notion of program. The category theoretic account of monad plays a very central role in exposing the generality of the abstraction (while Haskell's presentation has played a very central role in understanding the utility of such a general abstractin). A similarly axiomatic account of the separation of program from data could have applicability and utility we haven't even dreamed of yet. Best wishes, --greg * i simply cannot resist re-counting an insight that i got from Walter Fontana, Harvard Systems Biology, when we worked together. In some sense the dividing line between alchemy and chemistry is the periodic table. Before the development of the periodic table a good deal of human investigation of material properties could be seen as falling under the rubric alchemy. After it, chemistry. If you stare at the periodic table you see that the element names do not matter. They are merely convenient ways of referring to the positional information of the table. From a position in the table you can account for and predict all kind of properties of elements (notice that all the noble gases line up on the right!). Positions in the table -- kinds of element -- can be seen as 'names with structure', the structure of which determines the properties of instances of said kind. i believe that a first-principles account of the separation of program and data could have as big an impact on our understanding of the properties of computation as the development of the periodic table had on our understanding of material properties. On Mon, Nov 24, 2008 at 2:30 PM, Jonathan Cast wrote: > On Mon, 2008-11-24 at 14:06 -0800, Greg Meredith wrote: > > Haskellians, > > > Some monads come with take-out options, e.g. > > * List > > * Set > > In the sense that if unit : A -> List A is given by unit a = [a], then > > taking the head of a list can be used to retrieve values from inside > > the monad. > > > Some monads do not come with take-out options, IO being a notorious > > example. > > > Some monads, like Maybe, sit on the fence about take-out. They'll > > provide it when it's available. > > It might be pointed out that List and Set are also in this region. In > fact, Maybe is better, in this regard, since you know, if fromJust > succeeds, that it will only have once value to return. head might find > one value to return, no values, or even multiple values. > > A better example of a monad that always has a left inverse to return is > ((,) w), where w is a monoid. In this case, > > snd . return = id :: a -> a > > as desired (we always have the left inverses > > join . return = id :: m a -> m a > > where join a = a >>= id). > > > Now, are there references for a theory of monads and take-out options? > > For example, it seems that all sensible notions of containers have > > take-out. > > Sounds reasonable. Foldable gives you something: > > foldr const undefined > > will pull out the last value visited by foldr, and agrees with head at []. > > > Can we make the leap and define a container as a monad with a notion > > of take-out? > > If you want. I'd rather define a container to be Traversable; it > doesn't exclude anything interesting (that I'm aware of), and is mostly > more powerful. > > > Has this been done? > > Are you familiar at all with Foldable > ( > http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html#t%3AFoldable) > and Traversable ( > http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html#t%3ATraversable > ) > > jcc > > > -- 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/20081124/42d0a8ad/attachment.htm From john at repetae.net Mon Nov 24 18:10:28 2008 From: john at repetae.net (John Meacham) Date: Mon Nov 24 18:04:16 2008 Subject: [Haskell-cafe] Windows vs. Linux x64 In-Reply-To: <200811250056.27632.bartek@sudety.it> References: <200811250056.27632.bartek@sudety.it> Message-ID: <20081124231028.GF32430@sliver.repetae.net> Is the windows 32 or 64 bit, a while ago, ghc had trouble producing efficient binaries for 64 bit intel systems. Something about the interaction between gcc and the C it produced created some pessimal assembly output. I do not know how much this is still an issue though. You could try compiling 32 bit binaries under linux and running them on the same machine (they will work on the 64 bit system) and compare the results. John -- John Meacham - ?repetae.net?john? From john at repetae.net Mon Nov 24 18:14:51 2008 From: john at repetae.net (John Meacham) Date: Mon Nov 24 18:08:39 2008 Subject: [Haskell-cafe] monads with take-out options In-Reply-To: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com> References: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com> Message-ID: <20081124231451.GG32430@sliver.repetae.net> On Mon, Nov 24, 2008 at 02:06:33PM -0800, Greg Meredith wrote: > Now, are there references for a theory of monads and take-out options? For > example, it seems that all sensible notions of containers have take-out. Can > we make the leap and define a container as a monad with a notion of > take-out? Has this been done? Are there reasons for not doing? Can we say > what conditions are necessary to ensure a notion of take-out? Yes, you are describing 'co-monads'. here is an example that a quick web search brought up, and there was a paper on them and their properties published a while ago http://www.eyrie.org/~zednenem/2004/hsce/Control.Comonad.html the duals in that version are extract - return duplicate - join extend - flip (>>=) (more or less) John -- John Meacham - ?repetae.net?john? From duncan.coutts at worc.ox.ac.uk Mon Nov 24 18:38:30 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Nov 24 18:32:23 2008 Subject: [Haskell-cafe] Re: cabal install HaXml installs wrong version unless I specify the version number In-Reply-To: <910ddf450811240616h676d90bta5798671185ff01b@mail.gmail.com> References: <910ddf450811150302s3f8583baxe561a50856e2a337@mail.gmail.com> <910ddf450811150339u7920683do227dceb02383634f@mail.gmail.com> <1226750578.15832.12.camel@localhost> <910ddf450811150431ve395cb2gd9ade01e9d8c6a6a@mail.gmail.com> <1226756358.15832.25.camel@localhost> <910ddf450811240616h676d90bta5798671185ff01b@mail.gmail.com> Message-ID: <1227569910.19577.6.camel@localhost> On Mon, 2008-11-24 at 15:16 +0100, Thomas Hartman wrote: > I have run into another issue with cabal packaging, which seems > related to the issues discussed above. (see attached tar file for > complete example of failure scenario) > > If I have a cabal package that depends on two other packages > -- package xml-parsec requires HaXml == 1.19.4 (the latest) > -- package HAppS-Server requires HaXml == 1.13.3 (the default) > > ghc --make testDepConflict.hs > works fine. Yes, it happens to work. > But I can't install via cabal without, I guess, breaking out the > conflict into a separate cabal package. But cabal does not have enough information to know that it is going to work, and in many similar situations it'll fail. So it errs on the side of caution. The potential problem is that types defined in the two different versions of HaXml get used together in your package. Obviously that's not happening in your example but consider the case of different packages using different versions of the bytestring package and you would see type errors where different versions of the bytestring type get equated. Specifically the cabal install solver tries to find a solution that uses at most one version of each package. So that's why it declares that those two packages conflict. There's not a lot more we can do without having more information. For example if we know that the two packages you're using do not re-export any types from the HaXml package, and we could somehow declare and enforce such "private" build dependencies then that would be more information and the solver could allow private versions of a package to be different. Duncan From david.waern at gmail.com Mon Nov 24 18:41:09 2008 From: david.waern at gmail.com (David Waern) Date: Mon Nov 24 18:34:57 2008 Subject: [Haskell-cafe] Hackage/Cabal/Haddock question In-Reply-To: <167098.8478.qm@web65706.mail.ac4.yahoo.com> References: <167098.8478.qm@web65706.mail.ac4.yahoo.com> Message-ID: 2008/11/21 Robert Greayer : > How does Hackage run 'haddock' on uploaded packages? I had assumed it directly runs the cabal 'haddock' target, e.g. > > runhaskell Setup.hs haddock > > but it appears to perhaps be more complex than that. > > Some backrgound -- > > haddock doesn't seem to like quasiquotation - running haddock on a source tree that includes quasiquotations eventually results in: > > haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing > > (eliminating the code that contains [$xxx|....] constructs gets rid of the error.) It's true that haddock can't handle qasi-quotation. I've filed a bug ticket: http://trac.haskell.org/haddock/ticket/66 David From dons at galois.com Mon Nov 24 18:43:44 2008 From: dons at galois.com (Don Stewart) Date: Mon Nov 24 18:37:28 2008 Subject: [Haskell-cafe] Windows vs. Linux x64 In-Reply-To: <20081124231028.GF32430@sliver.repetae.net> References: <200811250056.27632.bartek@sudety.it> <20081124231028.GF32430@sliver.repetae.net> Message-ID: <20081124234344.GJ10286@scytale.galois.com> john: > Is the windows 32 or 64 bit, a while ago, ghc had trouble producing > efficient binaries for 64 bit intel systems. Something about the > interaction between gcc and the C it produced created some pessimal > assembly output. I do not know how much this is still an issue though. > You could try compiling 32 bit binaries under linux and running them on > the same machine (they will work on the 64 bit system) and compare the > results. > I get better code on x86_64/linux than on x86/linux, fwiw, thanks to my trusty gcc version 4.3.2. From claus.reinke at talk21.com Mon Nov 24 19:35:11 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Nov 24 19:29:06 2008 Subject: [Haskell-cafe] monads with take-out options References: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com><1227565803.31351.13.camel@jcchost> <5de3f5ca0811241506l66500d0bu8fb803c1e6ceba84@mail.gmail.com> Message-ID: <9CD6809993AD43479C6E7E96C7C6C73F@cr3lt> > - i am interested in a first-principles notion of data. Neither lambda > nor ?-calculus come with a criterion for determining which terms represent > data and which programs. You can shoe-horn in such notions -- and it is > clear that practical programming relies on such a separation -- but along > come nice abstractions like generic programming and the boundary starts > moving again. (Note, also that one of the reasons i mention ?-calculus is > because when you start shipping data between processes you'd like to know > that this term really is data and not some nasty little program...) I wouldn't call the usual representations of data in lambda shoe-horned (but perhaps you meant the criterion for distinguishing programs from data, not the notion of data?). Exposing data structures as nothing but placeholders for the contexts operating on their components, by making the structure components parameters to yet-to-be-determined continuations, seems to be as reduced to first-principles as one can get. It is also close to the old saying that "data are just dumb programs" (does anyone know who originated that phrase?) - when storage was tight, programmers couldn't always afford to fill it with dead code, so they encoded data in (the state of executing) their routines. When data was separated from real program code, associating data with the code needed to interpret it was still common. When high-level languages came along, treating programs as data (via reflective meta- programming, not higher order functions) remained desirable in some communities. Procedural abstraction was investigated as an alternative to abstract data types. Shipping an interpreter to run stored code was sometimes used to reduce memory footprint. If your interest is in security of mobile code, I doubt that you want to distinguish programs and data - "non-program" data which, when interpreted by otherwise safe-looking code, does nasty things, isn't much safer than code that does non-safe things directly. Unless you rule out code which may, depending on the data it operates on, do unwanted things, which is tricky without restricting expressiveness. More likely, you want to distinguish different kinds/types of programs/data, in terms of what using them together can do (in terms of pi-calculus, you're interested in typing process communication, restricting access to certain resources, or limiting communication to certain protocols). In the presence of suitably expressive type systems, procedural data abstractions need not be any less "safe" than dead bits interpreted by a separate program. Or if reasoning by suitable observational equivalences tells you that a piece of code can't do anything unsafe, does it matter whether that piece is program or data? That may be too simplistic for your purposes, but I thought I'd put in a word for the representation of data structures in lambda. Claus Ps. there have been lots of variation of pi-calculus, including some targetting more direct programming styles, such as the blue calculus (pi-calculus in direct style, Boudol et al). But I suspect you are aware of all that. From jwlato at gmail.com Mon Nov 24 20:30:10 2008 From: jwlato at gmail.com (John Lato) Date: Mon Nov 24 20:23:59 2008 Subject: [Haskell-cafe] build tools and Cabal Message-ID: <9979e72e0811241730n46ee2c06p1093f654f6896bee@mail.gmail.com> Hello, Cabal allows specifying arguments for tools it recognizes on the command line, e.g. runhaskell Setup.hs configure --c2hs-option=some_option Unfortunately, I can't find a way to make this work with .cabal (or .buildinfo) files, except for the specific cases of ghc, hugs, and nhc98 options. Am I missing something? If not, could this be added easily? It would be very helpful as I'm trying to work around the broken cpp Apple provides. Thanks, John From tphyahoo at gmail.com Mon Nov 24 22:00:42 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Mon Nov 24 21:54:29 2008 Subject: [Haskell-cafe] Hackage/Cabal/Haddock question In-Reply-To: <167098.8478.qm@web65706.mail.ac4.yahoo.com> References: <167098.8478.qm@web65706.mail.ac4.yahoo.com> Message-ID: <910ddf450811241900v12e3c339t6c379633bfb535c7@mail.gmail.com> I've noticed that many of the packages I upload to haddock don't build documentation properly, although the documentation builds fine locally when I run "cabal haddock". For example: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HAppSHelpers is fine in my local environment. I am not using quasiquotation. This also seems to be affecting many of the other happs bundles. thomas. 2008/11/21 Robert Greayer : > How does Hackage run 'haddock' on uploaded packages? I had assumed it directly runs the cabal 'haddock' target, e.g. > > runhaskell Setup.hs haddock > > but it appears to perhaps be more complex than that. > > Some backrgound -- > > haddock doesn't seem to like quasiquotation - running haddock on a source tree that includes quasiquotations eventually results in: > > haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing > > (eliminating the code that contains [$xxx|....] constructs gets rid of the error.) > > so "runhaskell Setup.hs haddock" ends up not generating any documentation. I worked around this problem by using a 'UserHook' and adding in an extra path element to the source path prior to running haddock via Cabal: > >> main = defaultMainWithHooks (simpleUserHooks { >> preHaddock = \_ _ -> return (Just $ emptyBuildInfo { hsSourceDirs = ["noqqsrc"]},[]) }) > > The additional directory contains an alternate version of modules that don't contain quasiquotation (just types and stubs), which seems to hide the versions that do. This works fine locally, but not on hackage (still get the same behavior in the build failure log). Of course, I'd prefer not to have to do this at all, so if anyone knows a way around the problem (or if its purely my problem -- I'm doing something wrong), I'd appreciate hearing about it. > > I'm using GHC 6.10.1, and have tried setup haddock with both the shipped-with-ghc version of haddock and the latest version. > > Thanks, > rcg > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From wren at freegeek.org Tue Nov 25 00:02:55 2008 From: wren at freegeek.org (wren ng thornton) Date: Mon Nov 24 23:56:44 2008 Subject: [Haskell-cafe] Request for code review: slice-1.0.0, TestSupport In-Reply-To: References: Message-ID: <492B86FF.1080504@freegeek.org> Owen Smith wrote: > Hi all, > > Thanks for your welcome and helpful comments. I've banged out a first > attempt at a Haskell library and was curious if anybody would have > time or interest in looking it over it for style, design, stuff that's > just wrong, or (most likely) stuff that's been done better elsewhere. > I'm willing to trade some labor in kind, if there's any odd jobs that > can be done by a relative newbie (e.g. maybe setting up a Windows box > for OpenGL build testing with GHC 6.10??). > > The library, slice, is an emulation of Python's list slicing mechanism: > > http://www.owendsmith.com/slice-1.0.0.tar.gz > > It uses a triple of Maybes to specify the range, so it's unwieldly in > terms of syntax, but the functionality should be there. This begs the question, why not use Haskell's enumeration syntax directly? That is, is there a specific reason you're using SliceParams instead of taking a list of indices as input? If you do the latter then Haskell already provides the [1,3..42] syntactic sugar (albeit, the second argument is the second element of the list with the step size inferred, rather than giving the step size explicitly). Upsides of lists of indices: * You can do Perl-style slicing where you can take the elements in whatever order you like, not just regular stepping orders. This is a two-edged sword, but it does make things much more concise than needing to manually stitch together a bunch of regular-step slices. * You can allow a step size of 0 in order to get an infinite list of the element at that index. (Of course, you can do this with the current implementation by just allowing it.) * You can piggyback on Haskell's syntactic sugar for regular step sequences. * Negative indices are easy: let l = length xs in xs `slice` map (\i -> if i < 0 then l+i else i) indices -- with some extra polish for boundary conditions. * It can potentially be generalized to operate over any indexable collection. (Maybe more tricky than it's worth, if you want to guarantee efficiency.) Downsides: * Handling Perlish slicing is trickier since you may need to jump arbitrarily far back into the part of the list you've already seen. It's especially tricky if you don't want to hold onto the whole list when you don't need it. * Constructing a list of indices from the [x,y..z] expression adds memory overhead if you don't do list fusion. (FWIW, using list fusion isn't too hard, heck you've basically rewritten a specialized case of it.) Implementation-wise, you should use Data.List.Extras.LazyLength[1] for dealing with those guards. When you just want to guarantee a list's length is above or below some bound, getting the actual full length always wastes time and generally wastes space as well (by not being least-strict). Similarly, if you do in fact need to get the full length of a list, you should bind it to a local variable so you needn't calculate it over and over. Also you can use case expressions (with a function like `compare`) to replace many of the guards more efficiently. In the same vein, the `slices` function can be made much more efficient if you actually do a round-robin, instead of traversing the list repeatedly for each slice. Round-robining is much easier than doing slicing right anyways. Finally, you may want to use Data.DList[2] in sliceRec, instead of constructing the list backwards and then reversing it. Difference lists have a constant-time append function, so you can eliminate the reversal thus saving O(m) time where m is the length of the list returned. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/list-extras [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dlist > Mostly, > besides gaining experience with writing a library, I wanted to have > functionality that skips through a list the way Python slices can, and > didn't see a particularly clean way of doing that particular kind of > list dicing in Data.List or elsewhere. A naive implementation of the arbitrary-indexing Perlish slicer: > xs `slice` indices = map (xs !!) indices Of course, this implementation is quite slow since it traverses the list from the beginning for each index. A smarter version would use something like a list zipper[3] so that the traversal time is bounded by the step size. In fact, difference lists can be thought of as a special case of zippers for lists.[4] [3] http://en.wikibooks.org/wiki/Haskell/Zippers [4] Where "special" means you only ever expand it down, and never move backwards. Difference lists can be generalized to other datastructures in the same way zippers can, though it seems much less common to do so. -- Live well, ~wren From allbery at ece.cmu.edu Tue Nov 25 01:45:06 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Nov 25 01:39:00 2008 Subject: [Haskell-cafe] monads with take-out options In-Reply-To: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com> References: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com> Message-ID: On 2008 Nov 24, at 17:06, Greg Meredith wrote: > Now, are there references for a theory of monads and take-out > options? For example, it seems that all sensible notions of > containers have take-out. Can we make the leap and define a > container as a monad with a notion of take-out? Has this been done? > Are there reasons for not doing? Can we say what conditions are > necessary to ensure a notion of take-out? Doesn't ST kinda fall outside the pale? (Well, it is a container of sorts, but a very different from Maybe or [].) -- 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/20081125/a1ea532b/attachment-0001.htm From lgreg.meredith at biosimilarity.com Tue Nov 25 01:48:16 2008 From: lgreg.meredith at biosimilarity.com (Greg Meredith) Date: Tue Nov 25 01:42:05 2008 Subject: [Haskell-cafe] monads with take-out options In-Reply-To: References: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com> Message-ID: <5de3f5ca0811242248n717a4b35l8583d5214352e9de@mail.gmail.com> Brandon, i see your point, but how do we sharpen that intuition to a formal characterization? Best wishes, --greg On Mon, Nov 24, 2008 at 10:45 PM, Brandon S. Allbery KF8NH < allbery@ece.cmu.edu> wrote: > On 2008 Nov 24, at 17:06, Greg Meredith wrote: > > Now, are there references for a theory of monads and take-out options? For > example, it seems that all sensible notions of containers have take-out. Can > we make the leap and define a container as a monad with a notion of > take-out? Has this been done? Are there reasons for not doing? Can we say > what conditions are necessary to ensure a notion of take-out? > > > Doesn't ST kinda fall outside the pale? (Well, it is a container of sorts, > but a very different from Maybe or [].) > > -- > 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 > > > -- 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/20081124/bfdd5f35/attachment.htm From lgreg.meredith at biosimilarity.com Tue Nov 25 02:09:22 2008 From: lgreg.meredith at biosimilarity.com (Greg Meredith) Date: Tue Nov 25 02:03:09 2008 Subject: [Haskell-cafe] monads with take-out options In-Reply-To: <9CD6809993AD43479C6E7E96C7C6C73F@cr3lt> References: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com> <1227565803.31351.13.camel@jcchost> <5de3f5ca0811241506l66500d0bu8fb803c1e6ceba84@mail.gmail.com> <9CD6809993AD43479C6E7E96C7C6C73F@cr3lt> Message-ID: <5de3f5ca0811242309o4318e2fwbb5046ad94b7ea29@mail.gmail.com> Claus, Thanks for your thoughtful response. Let me note that fully abstract semantics for PCF -- a total toy, mind you, just lambda + bools + naturals -- took some 25 years from characterization of the problem to a solution. That would seem to indicate shoe-horning, in my book ;-). Moreover, when i look at proposals to revisit Church versus Parigot encodings for data structures (ala Oliveira's thesis), i think we are still at the very beginnings of an understanding of how data fits into algebraic accounts of computation (such as lambda and ?-calculi). Obviously, we've come a long way. The relationship between types and pattern-matching, for example, is now heavily exploited and generally a good thing. But, do we really understand what's at work here -- or is this just another 'shut up and calculate' situation, like we have in certain areas of physics. Frankly, i think we are really just starting to understand what types are and how they relate to programs. This really begs fundamental questions. Can we give a compelling type-theoretic account of the separation of program from data? The existence of such an account has all kinds of implications, too. For example, the current "classification" of notions of quantity (number) is entirely one of history and accident. - Naturals - Rationals - Constructible - Algebraic - Transcendental - Reals - Complex - Infinitessimal - ... Can we give a type theoretic reconstruction of these notions (of traditional data types) that would unify -- or heaven forbid -- redraw the usual distinctions along lines that make more sense in terms of applications that provide value to users? Conway's ideas of numbers as games is remarkably unifying and captures all numbers in a single elegant data type. Can this (or something like it) be further rationally partitioned to provide better notions of numeric type? Is there a point where such an activity hits a wall and what we thought was data (real numbers; sequences of naturals; ...) are just too close to programs to be well served by data-centric treatments? Best wishes, --greg 2008/11/24 Claus Reinke > - i am interested in a first-principles notion of data. Neither lambda >> nor ?-calculus come with a criterion for determining which terms >> represent >> data and which programs. You can shoe-horn in such notions -- and it is >> clear that practical programming relies on such a separation -- but along >> come nice abstractions like generic programming and the boundary starts >> moving again. (Note, also that one of the reasons i mention ?-calculus is >> because when you start shipping data between processes you'd like to know >> that this term really is data and not some nasty little program...) >> > > I wouldn't call the usual representations of data in lambda shoe-horned > (but perhaps you meant the criterion for distinguishing programs from > data, not the notion of data?). Exposing data structures as nothing but > placeholders for the contexts operating on their components, by making > the structure components parameters to yet-to-be-determined continuations, > seems to be as reduced to first-principles as one can get. > > It is also close to the old saying that "data are just dumb programs" > (does anyone know who originated that phrase?) - when storage > was tight, programmers couldn't always afford to fill it with dead > code, so they encoded data in (the state of executing) their routines. > When data was separated from real program code, associating data > with the code needed to interpret it was still common. When high-level > languages came along, treating programs as data (via reflective meta- > programming, not higher order functions) remained desirable in some > communities. Procedural abstraction was investigated as an alternative > to abstract data types. Shipping an interpreter to run stored code was > sometimes used to reduce memory footprint. > > If your interest is in security of mobile code, I doubt that you want to > distinguish programs and data - "non-program" data which, when > interpreted by otherwise safe-looking code, does nasty things, isn't > much safer than code that does non-safe things directly. Unless you > rule out code which may, depending on the data it operates on, do > unwanted things, which is tricky without restricting expressiveness. > > More likely, you want to distinguish different kinds/types of > programs/data, in terms of what using them together can do (in > terms of pi-calculus, you're interested in typing process communication, > restricting access to certain resources, or limiting communication > to certain protocols). In the presence of suitably expressive type > systems, procedural data abstractions need not be any less "safe" > than dead bits interpreted by a separate program. Or if reasoning > by suitable observational equivalences tells you that a piece of code > can't do anything unsafe, does it matter whether that piece is > program or data? > > That may be too simplistic for your purposes, but I thought I'd put > in a word for the representation of data structures in lambda. > > Claus > > Ps. there have been lots of variation of pi-calculus, including > some targetting more direct programming styles, such as > the blue calculus (pi-calculus in direct style, Boudol et al). > But I suspect you are aware of all that. > > -- 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/20081124/d3a45e98/attachment.htm From lgreg.meredith at biosimilarity.com Tue Nov 25 03:08:18 2008 From: lgreg.meredith at biosimilarity.com (Greg Meredith) Date: Tue Nov 25 03:02:18 2008 Subject: [Haskell-cafe] re: monads with take-out options Message-ID: <5de3f5ca0811250008v59293de6g9d7ba1a18c8f2628@mail.gmail.com> John, You write: > Yes, you are describing 'co-monads'. > Good catch, but actually, that's too weak. i'm requesting something that is both a monad and a co-monad. That makes it something like a bi-algebra, or a Hopf algebra. This, however, is not the full story. i'm looking for a reference to the full story. Surely, someone has already developed this theory. Best wishes, --greg From: John Meacham Subject: Re: [Haskell-cafe] monads with take-out options To: haskell-cafe@haskell.org Message-ID: <20081124231451.GG32430@sliver.repetae.net> Content-Type: text/plain; charset=utf-8 On Mon, Nov 24, 2008 at 02:06:33PM -0800, Greg Meredith wrote: > Now, are there references for a theory of monads and take-out options? For > example, it seems that all sensible notions of containers have take-out. Can > we make the leap and define a container as a monad with a notion of > take-out? Has this been done? Are there reasons for not doing? Can we say > what conditions are necessary to ensure a notion of take-out? Yes, you are describing 'co-monads'. here is an example that a quick web search brought up, and there was a paper on them and their properties published a while ago http://www.eyrie.org/~zednenem/2004/hsce/Control.Comonad.html the duals in that version are extract - return duplicate - join extend - flip (>>=) (more or less) John -- John Meacham - ?repetae.net?john? -- 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/20081125/6c71a9ef/attachment.htm From bulat.ziganshin at gmail.com Tue Nov 25 04:32:21 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 25 04:26:29 2008 Subject: [Haskell-cafe] Windows vs. Linux x64 In-Reply-To: <20081124225902.GG10286@scytale.galois.com> References: <200811250056.27632.bartek@sudety.it> <20081124225902.GG10286@scytale.galois.com> Message-ID: <158388769.20081125123221@gmail.com> Hello Don, Tuesday, November 25, 2008, 1:59:02 AM, you wrote: > Is Windows running in 32 bit? What gcc versions are you using on each system? there is no 64-bit ghc for windows yet, and i think that 64-bit windows runs 32-bit programs as fast as 32-bit windows this problem naturally splits into two parts: 32-bit vs 64-bit and linux vs windows -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From david.waern at gmail.com Tue Nov 25 04:52:48 2008 From: david.waern at gmail.com (David Waern) Date: Tue Nov 25 04:46:36 2008 Subject: [Haskell-cafe] Hackage/Cabal/Haddock question In-Reply-To: <910ddf450811241900v12e3c339t6c379633bfb535c7@mail.gmail.com> References: <167098.8478.qm@web65706.mail.ac4.yahoo.com> <910ddf450811241900v12e3c339t6c379633bfb535c7@mail.gmail.com> Message-ID: 2008/11/25 Thomas Hartman : > I've noticed that many of the packages I upload to haddock don't build > documentation properly, although the documentation builds fine locally > when I run "cabal haddock". > > For example: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HAppSHelpers It seems like hackage doesn't have the required dependencies in this case. David From ross at soi.city.ac.uk Tue Nov 25 05:10:02 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Nov 25 05:03:52 2008 Subject: [Haskell-cafe] Hackage/Cabal/Haddock question In-Reply-To: References: <167098.8478.qm@web65706.mail.ac4.yahoo.com> <910ddf450811241900v12e3c339t6c379633bfb535c7@mail.gmail.com> Message-ID: <20081125101002.GA2911@soi.city.ac.uk> On Tue, Nov 25, 2008 at 10:52:48AM +0100, David Waern wrote: > 2008/11/25 Thomas Hartman : > > I've noticed that many of the packages I upload to haddock don't build > > documentation properly, although the documentation builds fine locally > > when I run "cabal haddock". > > > > For example: > > > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HAppSHelpers > > It seems like hackage doesn't have the required dependencies in this case. Yes, it seems syb-with-class and hspread don't build with ghc-6.10.1 and haddock-2.3.0. From lrpalmer at gmail.com Tue Nov 25 07:40:37 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Nov 25 07:34:23 2008 Subject: [Haskell-cafe] Unique functor instance Message-ID: <7ca3f0160811250440x373f2473s3ea3164de7f986ea@mail.gmail.com> I've been wondering, is it ever possible to have two (extensionally) different Functor instances for the same type? I do mean in Haskell; i.e. (,) doesn't count. I've failed to either come up with any examples or prove that they all must be the same using the laws. Thanks, Luke From voigt at tcs.inf.tu-dresden.de Tue Nov 25 08:21:51 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Tue Nov 25 08:15:37 2008 Subject: [Haskell-cafe] Unique functor instance In-Reply-To: <7ca3f0160811250440x373f2473s3ea3164de7f986ea@mail.gmail.com> References: <7ca3f0160811250440x373f2473s3ea3164de7f986ea@mail.gmail.com> Message-ID: <492BFBEF.3050501@tcs.inf.tu-dresden.de> Luke Palmer wrote: > I've been wondering, is it ever possible to have two (extensionally) > different Functor instances for the same type? I do mean in Haskell; > i.e. (,) doesn't count. I've failed to either come up with any > examples or prove that they all must be the same using the laws. For "not-too-exotic" datatypes, in particular for algebraic data types with polynomial structure (no exponentials, embedded function types, and other nasties), I would conjecture that indeed there is always exactly one Functor instance satisfying the identity and composition laws. But for proving this the two equational laws would not be enough. Rather, one would also need to use that fmap must be sufficiently polymorphic. Basically, a proof by a version of free theorems, or equivalently in this case, properties of natural transformations. And no, I don't have a more constructive proof at the moment ;-) Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From voigt at tcs.inf.tu-dresden.de Tue Nov 25 08:36:16 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Tue Nov 25 08:30:04 2008 Subject: [Haskell-cafe] Unique functor instance In-Reply-To: <492BFBEF.3050501@tcs.inf.tu-dresden.de> References: <7ca3f0160811250440x373f2473s3ea3164de7f986ea@mail.gmail.com> <492BFBEF.3050501@tcs.inf.tu-dresden.de> Message-ID: <492BFF50.8050402@tcs.inf.tu-dresden.de> Janis Voigtlaender wrote: > Luke Palmer wrote: > >> I've been wondering, is it ever possible to have two (extensionally) >> different Functor instances for the same type? I do mean in Haskell; >> i.e. (,) doesn't count. I've failed to either come up with any >> examples or prove that they all must be the same using the laws. > > > For "not-too-exotic" datatypes, in particular for algebraic data types > with polynomial structure (no exponentials, embedded function types, and > other nasties), I would conjecture that indeed there is always exactly > one Functor instance satisfying the identity and composition laws. > > But for proving this the two equational laws would not be enough. > Rather, one would also need to use that fmap must be sufficiently > polymorphic. Basically, a proof by a version of free theorems, or > equivalently in this case, properties of natural transformations. > > And no, I don't have a more constructive proof at the moment ;-) Let me be a bit more precise. A free theorem can be used to prove that any f :: (a -> b) -> [a] -> [b] which satisfies f id = id also satisfies f = map (for the Haskell standard map). Also, a free theorem can be used to prove that any f :: (a -> b) -> Tree a -> Tree b for data Tree a = Node (Tree a) (Tree a) | Leaf a which satisfies f id = id also satsifies f = fmap for the following definition: fmap f (Leaf a) = Leaf (f a) fmap f (Note t1 t2) = Node (fmap f t1) (fmap f t2) That gives the desired statement of "unique Functor instances" for the list type and the above Tree type. And the same kind of proof is possible for what I called "not-too-exotic" datatypes. And since all these proofs are essentially the same, it is no doubt possible to give a generic argument that provides the more general statement that for all such datatypes exactly one Functor instance exists. Makes sense? Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From claus.reinke at talk21.com Tue Nov 25 08:37:47 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Nov 25 08:31:38 2008 Subject: [Haskell-cafe] Unique functor instance References: <7ca3f0160811250440x373f2473s3ea3164de7f986ea@mail.gmail.com> <492BFBEF.3050501@tcs.inf.tu-dresden.de> Message-ID: <8E68F636A71440B1B68B55C9A9FE5BAA@cr3lt> > Luke Palmer wrote: >> I've been wondering, is it ever possible to have two (extensionally) >> different Functor instances for the same type? I do mean in Haskell; >> i.e. (,) doesn't count. I've failed to either come up with any >> examples or prove that they all must be the same using the laws. > > For "not-too-exotic" datatypes, in particular for algebraic data types > with polynomial structure (no exponentials, embedded function types, and > other nasties), I would conjecture that indeed there is always exactly > one Functor instance satisfying the identity and composition laws. Are identity and composition sufficient to guarantee that the mapped function is actually applied? instance Functor f where fmap _ x = x fmap id fx ~ fx ~ id fx fmap f (fmap g fx) ~ fmap f fx ~ fx ~ fmap (f . g) fx Claus From claus.reinke at talk21.com Tue Nov 25 08:40:57 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Nov 25 08:34:47 2008 Subject: [Haskell-cafe] Unique functor instance References: <7ca3f0160811250440x373f2473s3ea3164de7f986ea@mail.gmail.com><492BFBEF.3050501@tcs.inf.tu-dresden.de> <8E68F636A71440B1B68B55C9A9FE5BAA@cr3lt> Message-ID: > Are identity and composition sufficient to guarantee that the > mapped function is actually applied? eek - f :: a -> b, not f :: a -> a, so that example doesn't work !! Sorry for the noise, Claus From voigt at tcs.inf.tu-dresden.de Tue Nov 25 08:42:14 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Tue Nov 25 08:36:03 2008 Subject: [Haskell-cafe] Unique functor instance In-Reply-To: <8E68F636A71440B1B68B55C9A9FE5BAA@cr3lt> References: <7ca3f0160811250440x373f2473s3ea3164de7f986ea@mail.gmail.com> <492BFBEF.3050501@tcs.inf.tu-dresden.de> <8E68F636A71440B1B68B55C9A9FE5BAA@cr3lt> Message-ID: <492C00B6.6070201@tcs.inf.tu-dresden.de> Claus Reinke wrote: >> Luke Palmer wrote: >> >>> I've been wondering, is it ever possible to have two (extensionally) >>> different Functor instances for the same type? I do mean in Haskell; >>> i.e. (,) doesn't count. I've failed to either come up with any >>> examples or prove that they all must be the same using the laws. >> >> >> For "not-too-exotic" datatypes, in particular for algebraic data types >> with polynomial structure (no exponentials, embedded function types, and >> other nasties), I would conjecture that indeed there is always exactly >> one Functor instance satisfying the identity and composition laws. > > > Are identity and composition sufficient to guarantee that the > mapped function is actually applied? > > instance Functor f where fmap _ x = x Such an fmap will not have the required type (a -> b) -> f a -> f b Consider "fmap even". Then a=Int, b=Bool, x::f Int, (fmap even x)::f Bool, type error since you assumed fmap even x = x ! Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From d at vidplace.com Tue Nov 25 08:45:28 2008 From: d at vidplace.com (David F. Place) Date: Tue Nov 25 08:38:09 2008 Subject: [Haskell-cafe] Data.Array.Storable vs GC Message-ID: <1227620728.3207.5.camel@Congo> If you have a giant unboxed array that will never become garbage, it would be nice to put it somewhere where the GC won't bother with it. Since Data.Array.Storable arrays are allocated in the C heap, I thought it would be a good choice. However, I am getting very poor performance due to the GC copying 6G in each run. The only explanation that I can think of is that it is copying my giant array. Am I wrong in my understanding that Data.Array.Storable arrays should not be copied by the GC? BTW, I am using GHC 6.10.1 on linux. Thanks for reading. From voigt at tcs.inf.tu-dresden.de Tue Nov 25 08:49:58 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Tue Nov 25 08:43:44 2008 Subject: [Haskell-cafe] Unique functor instance In-Reply-To: <492BFF50.8050402@tcs.inf.tu-dresden.de> References: <7ca3f0160811250440x373f2473s3ea3164de7f986ea@mail.gmail.com> <492BFBEF.3050501@tcs.inf.tu-dresden.de> <492BFF50.8050402@tcs.inf.tu-dresden.de> Message-ID: <492C0286.6000002@tcs.inf.tu-dresden.de> Janis Voigtlaender wrote: > A free theorem can be used to prove that any > > f :: (a -> b) -> [a] -> [b] > > which satisfies > > f id = id > > also satisfies > > f = map (for the Haskell standard map). Here comes the full proof. Feed http://linux.tcs.inf.tu-dresden.de/~voigt/ft/ with the type of f. The output is: For every f :: forall a b . (a -> b) -> [a] -> [b] holds: forall t1,t2 in TYPES, g :: t1 -> t2. forall t3,t4 in TYPES, h :: t3 -> t4. forall p :: t1 -> t3. forall q :: t2 -> t4. (forall x :: t1. h (p x) = q (g x)) ==> (forall y :: [t1]. map h (f p y) = f q (map g y)) Set p = id and g = id. It results: forall t3,t4 in TYPES, h :: t3 -> t4. forall q :: t3 -> t4. (forall x :: t3. h (id x) = q (id x)) ==> (forall y :: [t3]. map h (f id y) = f q (map id y)) The precondition is obviously fulfilled whenever h = q. So we get, for every h, forall y :: [t3]. map h (f id y) = f h (map id y) Now note that we assume f id = id, and also know map id = id. This gives: forall y :: [t3]. map h y = f h y This is the desired extensional equivalence of map and f. All we needed was a free theorem and the identity law. The same kind of proof works for the Tree type, and friends. Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From bulat.ziganshin at gmail.com Tue Nov 25 08:51:19 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 25 08:45:17 2008 Subject: [Haskell-cafe] Data.Array.Storable vs GC In-Reply-To: <1227620728.3207.5.camel@Congo> References: <1227620728.3207.5.camel@Congo> Message-ID: <886674103.20081125165119@gmail.com> Hello David, Tuesday, November 25, 2008, 4:45:28 PM, you wrote: > However, I am getting very poor performance due to the GC copying 6G in > each run. The only explanation that I can think of is that it is > copying my giant array. each GC run? each program run? try to increase size of your array and check how many data are now copied by GC (of course, everything else shouldn't be changed) it's possible that your code that fills an array creates a lot of intermediate data -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From polyomino at f2s.com Tue Nov 25 09:02:25 2008 From: polyomino at f2s.com (DavidA) Date: Tue Nov 25 08:56:28 2008 Subject: [Haskell-cafe] Re: Unique functor instance References: <7ca3f0160811250440x373f2473s3ea3164de7f986ea@mail.gmail.com> Message-ID: Luke Palmer gmail.com> writes: > > I've been wondering, is it ever possible to have two (extensionally) > different Functor instances for the same type? I do mean in Haskell; > i.e. (,) doesn't count. I've failed to either come up with any > examples or prove that they all must be the same using the laws. > > Thanks, > Luke > A related question would be: are there two abstractions whose underlying representations (as algebraic data types) are isomorphic? For example, suppose that we represented both lists and sets as [a]. One would expect the Functor instances for list and set to be different, since sets can't contain duplicates. Unfortunately, it's not possible to express this in Haskell, because we can't assume an Eq constraint when defining our Functor instance. I suspect that the answer to the question is, yes, you can have different Functor instances. All you need is a sum-product type that it's possible to interpret as two different abstractions, leading to two different Functor instances. From marlowsd at gmail.com Tue Nov 25 09:07:48 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 25 09:01:39 2008 Subject: [Haskell-cafe] Re: Problem getting code from AFP08 parallel tutorial to run in parallel In-Reply-To: <20081124185140.GC7952@scytale.galois.com> References: <20081124185140.GC7952@scytale.galois.com> Message-ID: <492C06B4.4030401@gmail.com> Don Stewart wrote: > Which version of GHC are you using? > > This particular example triggers a "boundary condition" in ghc 6.10 > where, with only one spark, GHC doesn't fire up the extra cpu. Try it > with 6.8.x to see that in action. > > Simon Marlow may be able to comment more. Yes, it's a scheduling bug. I'll make sure it gets fixed for 6.10.2. If you have more sparks then you shouldn't see this problem. Also, GHC HEAD is quite a lot better with parallel programs than 6.10.1, I'll try to get around to posting some figures sometime. Cheers, Simon > -- Don > > olivier.boudry: >> Hi all, >> >> I'm reading the following tutorial: >> http://research.microsoft.com/~simonpj/papers/parallel/AFP08-notes.pdf >> "A Tutorial on Parallel and Concurrent >> Programming in Haskell" and have problems getting the expected speed >> improvement from running two tasks in parallel. With any version of >> the code present in pages 1-7 of the tutorial I keep getting the CPU >> stick to 50%. >> >> I did not forget to compile the code with `-threaded` and run it with >> `+RTS -N2` and it runs on a dual core machine on which I already used >> the Control.Parallel.Strategies.parMap function and got 100% CPU >> usage. >> >> The first version of the parallel function in the tutorial (page 6) is: >> >> parSumFibEuler :: Int ?> Int ?> Int >> parSumFibEuler a b >> = f 'par' (f + e) >> where >> f = fib a >> e = sumEuler b >> >> In the tutorial, swapping f and e on the 3rd line does the job, but in >> my case it doesn't change anything. >> >> C:\Temp\haskell>ghc --make -threaded SumEulerP6.hs >> [1 of 1] Compiling Main ( SumEulerP6.hs, SumEulerP6.o ) >> Linking SumEulerP6.exe ... >> >> C:\Temp\haskell>SumEulerP6 +RTS -N1 >> sum: 119201850 >> time: 36.890625 seconds >> >> C:\Temp\haskell>SumEulerP6 +RTS -N2 >> sum: 119201850 >> time: 36.859375 seconds >> >> Next page of the tutorial the tasks are explicitly sequenced so the >> code does not depend on the ordering of the two `+` operands: >> >> parSumFibEuler :: Int -> Int -> Int >> parSumFibEuler a b >> = f `par` (e `pseq` (f + e)) >> where >> f = fib a >> e = sumEuler b >> >> With once again a disappointing result: >> >> C:\Temp\haskell>ghc --make -threaded SumEulerP7.hs >> [1 of 1] Compiling Main ( SumEulerP7.hs, SumEulerP7.o ) >> Linking SumEulerP7.exe ... >> >> C:\Temp\haskell>SumEulerP7 +RTS -N1 >> sum: 119201850 >> time: 36.875 seconds >> >> C:\Temp\haskell>SumEulerP7 +RTS -N2 >> sum: 119201850 >> time: 36.75 seconds >> >> I tried this on a Windows XP Dell Dual Core with GHC 6.10.1 and on a >> iMac Dual Core with GHC 6.8.3 and got the same result on both. I'm >> probably missing something really stupid but I'm lacking the "parallel >> thinking" skills to understand how to look at the problem and resolve >> it. >> >> Any pointers? >> >> Thanks, >> >> Olivier. > >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe From voigt at tcs.inf.tu-dresden.de Tue Nov 25 09:09:51 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Tue Nov 25 09:03:38 2008 Subject: [Haskell-cafe] Re: Unique functor instance In-Reply-To: References: <7ca3f0160811250440x373f2473s3ea3164de7f986ea@mail.gmail.com> Message-ID: <492C072F.8050400@tcs.inf.tu-dresden.de> DavidA wrote: > I suspect that the answer to the question is, yes, you can have different > Functor instances. All you need is a sum-product type that it's possible to > interpret as two different abstractions, leading to two different Functor > instances. The sum-product types are exactly the "not-too-exotic" types to which my proof applies. So as long as extensional equivalence means Haskell equivalence, and not some "modulo an interpretation" equivalence (like considering two lists equivalent if they contain the same elements but in potentially different order), the answer is no, one cannot have different funtor instances. Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From tolis-f at hotmail.com Tue Nov 25 09:13:08 2008 From: tolis-f at hotmail.com (apostolos flessas) Date: Tue Nov 25 09:06:55 2008 Subject: [Haskell-cafe] (no subject) Message-ID: hi, i am looking for someone to help me with an assignment! can anyone help me? i am looking forward to your reply. sincerely, Tolis _________________________________________________________________ BigSnapSearch.com - 24 prizes a day, every day - Search Now! http://clk.atdmt.com/UKM/go/117442309/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081125/6c26b803/attachment.htm From d at vidplace.com Tue Nov 25 09:27:51 2008 From: d at vidplace.com (David F. Place) Date: Tue Nov 25 09:20:30 2008 Subject: [Haskell-cafe] Data.Array.Storable vs GC In-Reply-To: <886674103.20081125165119@gmail.com> References: <1227620728.3207.5.camel@Congo> <886674103.20081125165119@gmail.com> Message-ID: <1227623271.3207.14.camel@Congo> On Tue, 2008-11-25 at 16:51 +0300, Bulat Ziganshin wrote: > Hello David, Hello Bulat, > > Tuesday, November 25, 2008, 4:45:28 PM, you wrote: > > > However, I am getting very poor performance due to the GC copying 6G in > > each run. The only explanation that I can think of is that it is > > copying my giant array. > > each GC run? each program run? each program run > > try to increase size of your array and check how many data are now > copied by GC (of course, everything else shouldn't be changed) Excellent idea. I made the array twice as big, Otherwise everything else is the same. The GC copies the same amount of data. The only difference I noticed is that with the array twice as big, there were about half as many collections in generation 1. The time and efficiency are about the same. I guess it is not the fault of Data.Array.Storable. When I was researching how to do this, I was really hoping for something like "static areas" from the Lisp Machine operating system. You could allocate any normal object in an area of the heap where the GC would not bother with it. I miss that. I wonder why GHC doesn't have such a concept? From bulat.ziganshin at gmail.com Tue Nov 25 09:32:38 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 25 09:27:19 2008 Subject: [Haskell-cafe] Data.Array.Storable vs GC In-Reply-To: <1227623271.3207.14.camel@Congo> References: <1227620728.3207.5.camel@Congo> <886674103.20081125165119@gmail.com> <1227623271.3207.14.camel@Congo> Message-ID: <16310693532.20081125173238@gmail.com> Hello David, Tuesday, November 25, 2008, 5:27:51 PM, you wrote: > When I was researching how to do this, I was really hoping for something > like "static areas" from the Lisp Machine operating system. You could > allocate any normal object in an area of the heap where the GC would not > bother with it. I miss that. I wonder why GHC doesn't have such a > concept? it has. bytestrings use this area, it's called "pinned arrays" -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dougal at dougalstanton.net Tue Nov 25 09:41:16 2008 From: dougal at dougalstanton.net (Dougal Stanton) Date: Tue Nov 25 09:35:02 2008 Subject: [Haskell-cafe] (no subject) In-Reply-To: References: Message-ID: <2d3641330811250641r1731a533i12e14d5fbaa80a2a@mail.gmail.com> 2008/11/25 apostolos flessas : > hi, > > i am looking for someone to help me with an assignment! > can anyone help me? Hi Tolis! Have a look at the homework help policy, so you know what people will and will not answer. http://www.haskell.org/haskellwiki/Homework_help Then let us know what you're trying to do, and what your difficulty has been. Cheers, D From d at vidplace.com Tue Nov 25 09:50:18 2008 From: d at vidplace.com (David F. Place) Date: Tue Nov 25 09:43:00 2008 Subject: [Haskell-cafe] Data.Array.Storable vs GC In-Reply-To: <16310693532.20081125173238@gmail.com> References: <1227620728.3207.5.camel@Congo> <886674103.20081125165119@gmail.com> <1227623271.3207.14.camel@Congo> <16310693532.20081125173238@gmail.com> Message-ID: <1227624618.3207.16.camel@Congo> On Tue, 2008-11-25 at 17:32 +0300, Bulat Ziganshin wrote: > Hello David, > > Tuesday, November 25, 2008, 5:27:51 PM, you wrote: > > > When I was researching how to do this, I was really hoping for something > > like "static areas" from the Lisp Machine operating system. You could > > allocate any normal object in an area of the heap where the GC would not > > bother with it. I miss that. I wonder why GHC doesn't have such a > > concept? > > it has. bytestrings use this area, it's called "pinned arrays" > Thanks. I'll look into it. BTW, running my program with the compacting GC improved efficiency dramatically. Your initial idea that it was my other data was my other data was absolutely correct. From olivier.boudry at gmail.com Tue Nov 25 10:02:41 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Tue Nov 25 09:56:27 2008 Subject: [Haskell-cafe] Re: Problem getting code from AFP08 parallel tutorial to run in parallel In-Reply-To: <492C06B4.4030401@gmail.com> References: <20081124185140.GC7952@scytale.galois.com> <492C06B4.4030401@gmail.com> Message-ID: On Tue, Nov 25, 2008 at 3:07 PM, Simon Marlow wrote: > Yes, it's a scheduling bug. I'll make sure it gets fixed for 6.10.2. If > you have more sparks then you shouldn't see this problem. Also, GHC HEAD is > quite a lot better with parallel programs than 6.10.1, I'll try to get > around to posting some figures sometime. Yes, I tried it with 3 sparks and it works, Thanks for your help, Olivier. From polyomino at f2s.com Tue Nov 25 10:33:21 2008 From: polyomino at f2s.com (DavidA) Date: Tue Nov 25 10:27:19 2008 Subject: [Haskell-cafe] Re: Unique functor instance References: <7ca3f0160811250440x373f2473s3ea3164de7f986ea@mail.gmail.com> <492C072F.8050400@tcs.inf.tu-dresden.de> Message-ID: Janis Voigtlaender tcs.inf.tu-dresden.de> writes: > > DavidA wrote: > > I suspect that the answer to the question is, yes, you can have different > > Functor instances. All you need is a sum-product type that it's possible to > > interpret as two different abstractions, leading to two different Functor > > instances. > > The sum-product types are exactly the "not-too-exotic" types to which my > proof applies. So as long as extensional equivalence means Haskell > equivalence, and not some "modulo an interpretation" equivalence (like > considering two lists equivalent if they contain the same elements but > in potentially different order), the answer is no, one cannot have > different funtor instances. > > Ciao, Janis. > Okay, I see. Well that's interesting, because it suggests that your proof might break under modest extensions to the language. The thing that led me to suggest list / set as an example was consideration of Data.Set. Conceptually, this should be a Functor instance - given f :: a -> b, we should be able to derive fmap f :: Data.Set a -> Data.Set b, eg fmap f xs = (fromList . map f . toList) xs However, we can't currently express this in Haskell, because Data.Set requires Ord a. However, there have been some proposals to fix this. I assume that if they went through, then it would be possible to define a type which could be interpreted as either a list or a set, with different functor instances in either case. From tphyahoo at gmail.com Tue Nov 25 10:38:26 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Tue Nov 25 10:32:12 2008 Subject: [Haskell-cafe] Password hashing In-Reply-To: <75960862.20081030172321@gmail.com> References: <6205bd290810280842lc419882w80f144828b8d56cb@mail.gmail.com> <1041538055.20081028184923@gmail.com> <916b84820810291727tb2c3e0au3df64232f3636a87@mail.gmail.com> <22f6a8f70810291732k1f72fd04w8b4669ad4e75d4a1@mail.gmail.com> <910ddf450810300532l4cc15d4dn65f84faf59d23d3e@mail.gmail.com> <75960862.20081030172321@gmail.com> Message-ID: <910ddf450811250738l667d3b4dn9cffb05fa8e10374@mail.gmail.com> What does haskell cafe think of the following module for drop-in password hasing for webapps? Seem reasonable? import Data.Digest.SHA512 (hash) import qualified Data.ByteString as B' import qualified Data.ByteString.Char8 as B -- store passwords as md5 hash, as a security measure scramblepass :: String -> IO String scramblepass p = do etSalt <- try $ readFile "secure/salt" case etSalt of Left e -> fail errmsg Right s -> -- return . show . md5 . L.pack $ p ++ s return . B.unpack . B'.pack . hash . B'.unpack . B.pack $ p ++ s where errmsg = "scramblepass error, you probably need to create a salt file in secure/salt. This is used for \ \hashing passwords, so keep it secure. chmod u=r secure/salt, and make sure it's skipped \ \in version control commits, etc. A good way to generate a salt file is (e.g., on ubuntu) \ \writeFile \"secure/salt\" =<< ( strongsalt $ readFile \"/dev/urandom\")\ \You could also just type some random seeming text into this file, though that's not quite as secure.\ \Keep a backup copy of this file somewhere safe in case of disaster." -- | eg, on ubuntu: strongsalt $ readFile "/dev/urandom" strongsalt :: IO String -> IO String strongsalt randomSource = return . salt' =<< randomSource where salt' = show . fst . next . mkStdGen . read . concat . map (show . ord) . take 10 2008/10/30 Bulat Ziganshin : > Hello Thomas, > > Thursday, October 30, 2008, 3:32:46 PM, you wrote: > >> No salt, but apart from that, should be fine, right? > > 1) without salt, it's not serious - easily breaked by dictionary > attack > > 2) afair, md5 isn't condidered now as cryptographic hash > > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > From tphyahoo at gmail.com Tue Nov 25 10:39:27 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Tue Nov 25 10:33:13 2008 Subject: [Haskell-cafe] Password hashing In-Reply-To: <910ddf450811250738l667d3b4dn9cffb05fa8e10374@mail.gmail.com> References: <6205bd290810280842lc419882w80f144828b8d56cb@mail.gmail.com> <1041538055.20081028184923@gmail.com> <916b84820810291727tb2c3e0au3df64232f3636a87@mail.gmail.com> <22f6a8f70810291732k1f72fd04w8b4669ad4e75d4a1@mail.gmail.com> <910ddf450810300532l4cc15d4dn65f84faf59d23d3e@mail.gmail.com> <75960862.20081030172321@gmail.com> <910ddf450811250738l667d3b4dn9cffb05fa8e10374@mail.gmail.com> Message-ID: <910ddf450811250739y5adca8fbncb543d458dfa9c70@mail.gmail.com> Just to note, the comment about md5 is incorrect. I switched to SHA512 as you can see in the code. 2008/11/25 Thomas Hartman : > What does haskell cafe think of the following module for drop-in > password hasing for webapps? Seem reasonable? > > import Data.Digest.SHA512 (hash) > import qualified Data.ByteString as B' > import qualified Data.ByteString.Char8 as B > > -- store passwords as md5 hash, as a security measure > scramblepass :: String -> IO String > scramblepass p = do > etSalt <- try $ readFile "secure/salt" > case etSalt of > Left e -> fail errmsg > Right s -> -- return . show . md5 . L.pack $ p ++ s > return . B.unpack . B'.pack . hash . B'.unpack . B.pack $ p ++ s > where errmsg = "scramblepass error, you probably need to create a > salt file in secure/salt. This is used for \ > \hashing passwords, so keep it secure. chmod u=r > secure/salt, and make sure it's skipped \ > \in version control commits, etc. A good way to generate a > salt file is (e.g., on ubuntu) \ > \writeFile \"secure/salt\" =<< ( strongsalt $ readFile > \"/dev/urandom\")\ > \You could also just type some random seeming text into > this file, though that's not quite as secure.\ > \Keep a backup copy of this file somewhere safe in case of > disaster." > > > -- | eg, on ubuntu: strongsalt $ readFile "/dev/urandom" > strongsalt :: IO String -> IO String > strongsalt randomSource = return . salt' =<< randomSource > where salt' = show . fst . next . mkStdGen . read . concat . map > (show . ord) . take 10 > > > > 2008/10/30 Bulat Ziganshin : >> Hello Thomas, >> >> Thursday, October 30, 2008, 3:32:46 PM, you wrote: >> >>> No salt, but apart from that, should be fine, right? >> >> 1) without salt, it's not serious - easily breaked by dictionary >> attack >> >> 2) afair, md5 isn't condidered now as cryptographic hash >> >> >> >> -- >> Best regards, >> Bulat mailto:Bulat.Ziganshin@gmail.com >> >> > From voigt at tcs.inf.tu-dresden.de Tue Nov 25 10:43:16 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Tue Nov 25 10:37:02 2008 Subject: [Haskell-cafe] Re: Unique functor instance In-Reply-To: References: <7ca3f0160811250440x373f2473s3ea3164de7f986ea@mail.gmail.com> <492C072F.8050400@tcs.inf.tu-dresden.de> Message-ID: <492C1D14.1070703@tcs.inf.tu-dresden.de> DavidA wrote: > Okay, I see. Well that's interesting, because it suggests that your proof > might break under modest extensions to the language. Yes. The free theorem used was a "naive" one, for the simplest possible model of Haskell, not even taking care of possible nontermination and seq. But http://linux.tcs.inf.tu-dresden.de/~voigt/ft/ can produce less naive ones as well. In particular, it can also produce free theorems for types involving class constraints, like Eq or Ord. That would deal with situations where the type variables a and b in the type of fmap were class-constrained, as you suggest. And finally, another plug: explanations for precisely the kind of type-based reasoning I used in the earlier mail can be found in the thesis I advertised today on the general list: http://wwwtcs.inf.tu-dresden.de/~voigt/habil.pdf Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From bulat.ziganshin at gmail.com Tue Nov 25 10:50:58 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 25 10:45:03 2008 Subject: [Haskell-cafe] Password hashing In-Reply-To: <910ddf450811250739y5adca8fbncb543d458dfa9c70@mail.gmail.com> References: <6205bd290810280842lc419882w80f144828b8d56cb@mail.gmail.com> <1041538055.20081028184923@gmail.com> <916b84820810291727tb2c3e0au3df64232f3636a87@mail.gmail.com> <22f6a8f70810291732k1f72fd04w8b4669ad4e75d4a1@mail.gmail.com> <910ddf450810300532l4cc15d4dn65f84faf59d23d3e@mail.gmail.com> <75960862.20081030172321@gmail.com> <910ddf450811250738l667d3b4dn9cffb05fa8e10374@mail.gmail.com> <910ddf450811250739y5adca8fbncb543d458dfa9c70@mail.gmail.com> Message-ID: <1754056698.20081125185058@gmail.com> Hello Thomas, Tuesday, November 25, 2008, 6:39:27 PM, you wrote: > Just to note, the comment about md5 is incorrect. I switched to SHA512 > as you can see in the code. really? :) >> Right s -> -- return . show . md5 . L.pack $ p ++ s typical salt usage is generation of new salt for every encryption operation and storing together with encrypted data -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jake at pikewerks.com Tue Nov 25 11:12:07 2008 From: jake at pikewerks.com (Jake McArthur) Date: Tue Nov 25 11:06:06 2008 Subject: [Haskell-cafe] Password hashing In-Reply-To: <1754056698.20081125185058@gmail.com> References: <6205bd290810280842lc419882w80f144828b8d56cb@mail.gmail.com> <1041538055.20081028184923@gmail.com> <916b84820810291727tb2c3e0au3df64232f3636a87@mail.gmail.com> <22f6a8f70810291732k1f72fd04w8b4669ad4e75d4a1@mail.gmail.com> <910ddf450810300532l4cc15d4dn65f84faf59d23d3e@mail.gmail.com> <75960862.20081030172321@gmail.com> <910ddf450811250738l667d3b4dn9cffb05fa8e10374@mail.gmail.com> <910ddf450811250739y5adca8fbncb543d458dfa9c70@mail.gmail.com> <1754056698.20081125185058@gmail.com> Message-ID: <492C23D7.2010102@pikewerks.com> Bulat Ziganshin wrote: >> Just to note, the comment about md5 is incorrect. I switched to SHA512 >> as you can see in the code. > > really? :) > >>> Right s -> -- return . show . md5 . L.pack $ p ++ s Yes, really. If you look carefully, it is commented out. ;) - Jake -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081125/dca8a1d1/signature.bin From tphyahoo at gmail.com Tue Nov 25 11:38:16 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Tue Nov 25 11:32:02 2008 Subject: [Haskell-cafe] Password hashing In-Reply-To: <1754056698.20081125185058@gmail.com> References: <6205bd290810280842lc419882w80f144828b8d56cb@mail.gmail.com> <1041538055.20081028184923@gmail.com> <916b84820810291727tb2c3e0au3df64232f3636a87@mail.gmail.com> <22f6a8f70810291732k1f72fd04w8b4669ad4e75d4a1@mail.gmail.com> <910ddf450810300532l4cc15d4dn65f84faf59d23d3e@mail.gmail.com> <75960862.20081030172321@gmail.com> <910ddf450811250738l667d3b4dn9cffb05fa8e10374@mail.gmail.com> <910ddf450811250739y5adca8fbncb543d458dfa9c70@mail.gmail.com> <1754056698.20081125185058@gmail.com> Message-ID: <910ddf450811250838k3c6c6f44x986404d42c832f32@mail.gmail.com> ah thanks, I'll try again. > typical salt usage is generation of new salt for every encryption >operation and storing together with encrypted data 2008/11/25 Bulat Ziganshin : > Hello Thomas, > > Tuesday, November 25, 2008, 6:39:27 PM, you wrote: > >> Just to note, the comment about md5 is incorrect. I switched to SHA512 >> as you can see in the code. > > really? :) > >>> Right s -> -- return . show . md5 . L.pack $ p ++ s > > typical salt usage is generation of new salt for every encryption > operation and storing together with encrypted data > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > From tphyahoo at gmail.com Tue Nov 25 11:58:08 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Tue Nov 25 11:51:54 2008 Subject: [Haskell-cafe] Hackage/Cabal/Haddock question In-Reply-To: <20081125101002.GA2911@soi.city.ac.uk> References: <167098.8478.qm@web65706.mail.ac4.yahoo.com> <910ddf450811241900v12e3c339t6c379633bfb535c7@mail.gmail.com> <20081125101002.GA2911@soi.city.ac.uk> Message-ID: <910ddf450811250858i150371dw94a2167d55dcbebc@mail.gmail.com> How come I get documentation output when I build locally then? I'm also using ghc 6.10.1 and haddock 2.3.0. 2008/11/25 Ross Paterson : > On Tue, Nov 25, 2008 at 10:52:48AM +0100, David Waern wrote: >> 2008/11/25 Thomas Hartman : >> > I've noticed that many of the packages I upload to haddock don't build >> > documentation properly, although the documentation builds fine locally >> > when I run "cabal haddock". >> > >> > For example: >> > >> > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HAppSHelpers >> >> It seems like hackage doesn't have the required dependencies in this case. > > Yes, it seems syb-with-class and hspread don't build with ghc-6.10.1 and > haddock-2.3.0. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From tphyahoo at gmail.com Tue Nov 25 13:13:53 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Tue Nov 25 13:07:40 2008 Subject: [Haskell-cafe] Password hashing In-Reply-To: <1754056698.20081125185058@gmail.com> References: <6205bd290810280842lc419882w80f144828b8d56cb@mail.gmail.com> <1041538055.20081028184923@gmail.com> <916b84820810291727tb2c3e0au3df64232f3636a87@mail.gmail.com> <22f6a8f70810291732k1f72fd04w8b4669ad4e75d4a1@mail.gmail.com> <910ddf450810300532l4cc15d4dn65f84faf59d23d3e@mail.gmail.com> <75960862.20081030172321@gmail.com> <910ddf450811250738l667d3b4dn9cffb05fa8e10374@mail.gmail.com> <910ddf450811250739y5adca8fbncb543d458dfa9c70@mail.gmail.com> <1754056698.20081125185058@gmail.com> Message-ID: <910ddf450811251013l6537612ble54cf7bb1adcf37d@mail.gmail.com> How about the following? The main doubts I'm having at this point concern the takerandom part. Does this seem reasonable? Also, someone in the thread mentioned that a calculation that took a couple of seconds to complete was a good thing because it makes dictionary cracking harder. But makeSaltedPasswordLinux "meh" is virtually instantaneous, so I guess I'm doing something wrong? Thanks for advice! thomas. thartman@thartman-laptop:~/hackage/HAppSHelpers>cat HAppS/Helpers/Security.hs -- | Password hashes are based on a salt from a source of randomness (eg /dev/urandom), and -- | the SHA512 hashing function module HAppS.Helpers.Security ( makeSaltedPassword, makeSaltedPasswordLinux, checkpass ) where import qualified Data.ByteString.Char8 as B import qualified Data.ByteString as B' import Control.Monad.Error import System.IO.Error import Random import Data.Digest.SHA512 (hash) import Data.Char data SaltedPassword = SaltedPassword HashedPass Salt deriving Show newtype Password = Password String deriving Show newtype Salt = Salt String deriving Show newtype HashedPass = HashedPass String deriving (Eq, Show) checkpass :: Password -> SaltedPassword -> Bool checkpass passattempt ( SaltedPassword hashedPass salt ) = let hashedPassAttempt = hashpass passattempt salt in hashedPassAttempt == hashedPass hashpass :: Password -> Salt -> HashedPass hashpass (Password p) (Salt s) = HashedPass . B.unpack . B'.pack . hash . B'.unpack . B.pack $ p ++ s -- | This works at least on ubuntu hardy heron, I don't know how portable it is -- > makeSaltedPasswordLinux p = getSaltedPassword $ readFile "/dev/urandom") makeSaltedPasswordLinux :: Password -> IO SaltedPassword makeSaltedPasswordLinux = makeSaltedPassword $ readFile "/dev/urandom" makeSaltedPassword :: IO String -> Password -> IO SaltedPassword makeSaltedPassword randomsource pass = do etR <- try $ return . takerandom =<< randomsource case etR of Left e -> fail . show $ e Right s -> do let salt = Salt s hp = hashpass pass salt return $ SaltedPassword hp salt takerandom :: String -> String takerandom = show . fst . next . mkStdGen . read . concat . map (show . ord) . take 1000 2008/11/25 Bulat Ziganshin : > Hello Thomas, > > Tuesday, November 25, 2008, 6:39:27 PM, you wrote: > >> Just to note, the comment about md5 is incorrect. I switched to SHA512 >> as you can see in the code. > > really? :) > >>> Right s -> -- return . show . md5 . L.pack $ p ++ s > > typical salt usage is generation of new salt for every encryption > operation and storing together with encrypted data > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > From mgg at giagnocavo.net Tue Nov 25 13:26:35 2008 From: mgg at giagnocavo.net (Michael Giagnocavo) Date: Tue Nov 25 13:20:21 2008 Subject: [Haskell-cafe] Password hashing In-Reply-To: <910ddf450811250738l667d3b4dn9cffb05fa8e10374@mail.gmail.com> References: <6205bd290810280842lc419882w80f144828b8d56cb@mail.gmail.com> <1041538055.20081028184923@gmail.com> <916b84820810291727tb2c3e0au3df64232f3636a87@mail.gmail.com> <22f6a8f70810291732k1f72fd04w8b4669ad4e75d4a1@mail.gmail.com> <910ddf450810300532l4cc15d4dn65f84faf59d23d3e@mail.gmail.com> <75960862.20081030172321@gmail.com> <910ddf450811250738l667d3b4dn9cffb05fa8e10374@mail.gmail.com> Message-ID: <6E8D2069C08AA84A83D336E996AE4C6702335FD4D8@mse17be1.mse17.exchange.ms> Some password hashing schemes will also perform a number of iterations to increase the attack time needed. (For instance, hashing 1024 times would increase the strength of the password against brute force by 10 bits.) Usually the iterations are stored unencrypted with the hash and salt so that the iterations can be changed as app needs do. There's even an RFC on the subject: http://www.ietf.org/rfc/rfc2898.txt (PBKDF2 is the function) -Michael -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Thomas Hartman Sent: Tuesday, November 25, 2008 8:38 AM To: Bulat Ziganshin; haskell-cafe; HAppS Subject: Re: Re[2]: [Haskell-cafe] Password hashing What does haskell cafe think of the following module for drop-in password hasing for webapps? Seem reasonable? import Data.Digest.SHA512 (hash) import qualified Data.ByteString as B' import qualified Data.ByteString.Char8 as B -- store passwords as md5 hash, as a security measure scramblepass :: String -> IO String scramblepass p = do etSalt <- try $ readFile "secure/salt" case etSalt of Left e -> fail errmsg Right s -> -- return . show . md5 . L.pack $ p ++ s return . B.unpack . B'.pack . hash . B'.unpack . B.pack $ p ++ s where errmsg = "scramblepass error, you probably need to create a salt file in secure/salt. This is used for \ \hashing passwords, so keep it secure. chmod u=r secure/salt, and make sure it's skipped \ \in version control commits, etc. A good way to generate a salt file is (e.g., on ubuntu) \ \writeFile \"secure/salt\" =<< ( strongsalt $ readFile \"/dev/urandom\")\ \You could also just type some random seeming text into this file, though that's not quite as secure.\ \Keep a backup copy of this file somewhere safe in case of disaster." -- | eg, on ubuntu: strongsalt $ readFile "/dev/urandom" strongsalt :: IO String -> IO String strongsalt randomSource = return . salt' =<< randomSource where salt' = show . fst . next . mkStdGen . read . concat . map (show . ord) . take 10 From bulat.ziganshin at gmail.com Tue Nov 25 13:31:04 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 25 13:25:07 2008 Subject: [Haskell-cafe] Password hashing In-Reply-To: <910ddf450811251013l6537612ble54cf7bb1adcf37d@mail.gmail.com> References: <6205bd290810280842lc419882w80f144828b8d56cb@mail.gmail.com> <1041538055.20081028184923@gmail.com> <916b84820810291727tb2c3e0au3df64232f3636a87@mail.gmail.com> <22f6a8f70810291732k1f72fd04w8b4669ad4e75d4a1@mail.gmail.com> <910ddf450810300532l4cc15d4dn65f84faf59d23d3e@mail.gmail.com> <75960862.20081030172321@gmail.com> <910ddf450811250738l667d3b4dn9cffb05fa8e10374@mail.gmail.com> <910ddf450811250739y5adca8fbncb543d458dfa9c70@mail.gmail.com> <1754056698.20081125185058@gmail.com> <910ddf450811251013l6537612ble54cf7bb1adcf37d@mail.gmail.com> Message-ID: <9510638993.20081125213104@gmail.com> Hello Thomas, Tuesday, November 25, 2008, 9:13:53 PM, you wrote: don't reinvent the wheel, use PBKDF2 from PKCS #5 http://www.truecrypt.org/docs/pkcs5v2-0.pdf > How about the following? > The main doubts I'm having at this point concern the takerandom part. > Does this seem reasonable? > Also, someone in the thread mentioned that a calculation that took a > couple of seconds to complete was a good thing because it makes > dictionary cracking harder. But > makeSaltedPasswordLinux "meh" > is virtually instantaneous, so I guess I'm doing something wrong? > Thanks for advice! > thomas. > thartman@thartman-laptop:~/hackage/HAppSHelpers>cat HAppS/Helpers/Security.hs > -- | Password hashes are based on a salt from a source of randomness > (eg /dev/urandom), and > -- | the SHA512 hashing function > module HAppS.Helpers.Security ( > makeSaltedPassword, makeSaltedPasswordLinux, checkpass > ) > where > import qualified Data.ByteString.Char8 as B > import qualified Data.ByteString as B' > import Control.Monad.Error > import System.IO.Error > import Random > import Data.Digest.SHA512 (hash) > import Data.Char > data SaltedPassword = SaltedPassword HashedPass Salt > deriving Show > newtype Password = Password String > deriving Show > newtype Salt = Salt String > deriving Show > newtype HashedPass = HashedPass String > deriving (Eq, Show) > checkpass :: Password -> SaltedPassword -> Bool > checkpass passattempt ( SaltedPassword hashedPass salt ) = > let hashedPassAttempt = hashpass passattempt salt > in hashedPassAttempt == hashedPass > hashpass :: Password -> Salt -> HashedPass > hashpass (Password p) (Salt s) = HashedPass . B.unpack . B'.pack . > hash . B'.unpack . B.pack $ p ++ s > -- | This works at least on ubuntu hardy heron, I don't know how portable it is -- >> makeSaltedPasswordLinux p = getSaltedPassword $ readFile "/dev/urandom") > makeSaltedPasswordLinux :: Password -> IO SaltedPassword > makeSaltedPasswordLinux = makeSaltedPassword $ readFile "/dev/urandom" > makeSaltedPassword :: IO String -> Password -> IO SaltedPassword > makeSaltedPassword randomsource pass = do > etR <- try $ return . takerandom =<< randomsource > case etR of > Left e -> fail . show $ e > Right s -> do let salt = Salt s > hp = hashpass pass salt > return $ SaltedPassword hp salt > takerandom :: String -> String > takerandom = show . fst . next . mkStdGen . read . concat . map (show > . ord) . take 1000 > 2008/11/25 Bulat Ziganshin : >> Hello Thomas, >> >> Tuesday, November 25, 2008, 6:39:27 PM, you wrote: >> >>> Just to note, the comment about md5 is incorrect. I switched to SHA512 >>> as you can see in the code. >> >> really? :) >> >>>> Right s -> -- return . show . md5 . L.pack $ p ++ s >> >> typical salt usage is generation of new salt for every encryption >> operation and storing together with encrypted data >> >> >> -- >> Best regards, >> Bulat mailto:Bulat.Ziganshin@gmail.com >> >> -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From andrewcoppin at btinternet.com Tue Nov 25 13:43:11 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Tue Nov 25 13:36:57 2008 Subject: [Haskell-cafe] Interactive In-Reply-To: <4c44d90b0811121358t49bdda16j8d2a7d9a0fbd2c30@mail.gmail.com> References: <491B5035.2030200@btinternet.com> <4c44d90b0811121358t49bdda16j8d2a7d9a0fbd2c30@mail.gmail.com> Message-ID: <492C473F.609@btinternet.com> Thomas DuBuisson wrote: > Here are the links that hold the information you desire: > http://www.haskell.org/haskellwiki/Frag > http://www.cse.unsw.edu.au/~pls/thesis/munc-thesis.pdf > > > In short: FRP > http://www.haskell.org/frp/ > > On Wed, Nov 12, 2008 at 1:52 PM, Andrew Coppin > > wrote: > > I have a small question... > > Given that interactivity is Really Hard to do in Haskell, and that > mutable state is to be strongly avoided, how come Frag exists? > (I.e., how did they successfully solve these problems?) > Having read the paper [again], I'm still don't understand a word of it. So I'm still wondering how Frag actually works. OOP seems like such a natural fit for describing the behaviour of a network of independent objects. But Haskell seems to require you to make a new, modified copy of the entire game state at each frame, which sounds... highly non-performant. What am I not seeing? From jonathanccast at fastmail.fm Tue Nov 25 13:48:51 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Tue Nov 25 13:43:04 2008 Subject: [Haskell-cafe] Interactive In-Reply-To: <492C473F.609@btinternet.com> References: <491B5035.2030200@btinternet.com> <4c44d90b0811121358t49bdda16j8d2a7d9a0fbd2c30@mail.gmail.com> <492C473F.609@btinternet.com> Message-ID: <1227638931.4505.9.camel@jcchost> On Tue, 2008-11-25 at 18:43 +0000, Andrew Coppin wrote: > Thomas DuBuisson wrote: > > Here are the links that hold the information you desire: > > http://www.haskell.org/haskellwiki/Frag > > http://www.cse.unsw.edu.au/~pls/thesis/munc-thesis.pdf > > > > > > In short: FRP > > http://www.haskell.org/frp/ > > > > On Wed, Nov 12, 2008 at 1:52 PM, Andrew Coppin > > > wrote: > > > > I have a small question... > > > > Given that interactivity is Really Hard to do in Haskell, and that > > mutable state is to be strongly avoided, how come Frag exists? > > (I.e., how did they successfully solve these problems?) > > > > Having read the paper [again], I'm still don't understand a word of it. > So I'm still wondering how Frag actually works. > > OOP seems like such a natural fit for describing the behaviour of a > network of independent objects. But Haskell seems to require you to make > a new, modified copy of the entire game state at each frame, Small note: this depends on the data structure. Some structures allow for large amounts of state sharing; in particular, the old copy of any object that didn't change can probably be re-used. I don't know how much that applies to Frag, but I've found it to be quite helpful performance-wise in the past. And, in general, most of the interest in FRP isn't in making functions over time work --- that's easy --- but in minimizing re-computation, which includes precisely re-using earlier results when possible. jcc From jonathanccast at fastmail.fm Tue Nov 25 14:12:32 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Tue Nov 25 14:06:20 2008 Subject: [Haskell-cafe] monads with take-out options In-Reply-To: <5de3f5ca0811241506l66500d0bu8fb803c1e6ceba84@mail.gmail.com> References: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com> <1227565803.31351.13.camel@jcchost> <5de3f5ca0811241506l66500d0bu8fb803c1e6ceba84@mail.gmail.com> Message-ID: <1227640352.4505.33.camel@jcchost> On Mon, 2008-11-24 at 15:06 -0800, Greg Meredith wrote: > Jonathan, > Nice! Thanks. In addition to implementations, do we have more > mathematical accounts? Let me expose more of my motives. > * i am interested in a first-principles notion of data. Hunh. I have to say I'm not. The difference between Bool -> alpha and (alpha, alpha) is not one I've ever felt a need to elaborate. And I'm not sure you *could* elaborate it, within a mathematical context --- which to me means you only work up to isomorphism anyway. > Neither lambda nor ?-calculus come with a criterion for > determining which terms represent data and which programs. As you know, lambda-calculus was originally designed to provide a foundation for mathematics in which every mathematical object --- sets, numbers, function, etc. --- would be a function (a lambda-term) under the hood. It was designed to abstract away the distinction between values and functions, not really to express it. > You can shoe-horn in such notions -- and it is clear that > practical programming relies on such a separation What? `Practical programming' in my experience relies on the readiness to see functions as first-class values (as near to data as possible). Implementations want to distinguish them, in various ways --- but then once you draw that distinction, programmers want to use data structures like tries, to get your `data structure' implementation for the program design's `function' types (or some of them...) As near as I can tell, the distinction between data and code is fundamentally one of performance, which makes it quite implementation-dependent. And, for me, boring. > -- but along come nice abstractions like generic programming > and the boundary starts moving again. > (Note, also that one of the reasons i mention ?-calculus is > because when you start shipping data between processes you'd > like to know that this term really is data and not some nasty > little program...) It's not nice to call my children^Wprograms nasty :) I think, though, that the real problem is to distinguish values with finite canonical forms (which can be communicated to another process in finite time) from values with infinite canonical forms (which cannot). The problem then is defining what a `canonical form' is. But characterizing the problem in terms of data vs. code isn't going to help: \ b -> if b then 0 else 1 is a perfectly good finite canonical form of type Bool -> Int, while repeat 0 is a perfectly good term of type [Int] (a data type!) with no finite canonical form (not even a finite normal form). I'm sure this fails to engage your point, but perhaps it might clarify some points you hadn't considered. jcc From bulat.ziganshin at gmail.com Tue Nov 25 14:27:04 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 25 14:21:17 2008 Subject: [Haskell-cafe] Interactive In-Reply-To: <492C473F.609@btinternet.com> References: <491B5035.2030200@btinternet.com> <4c44d90b0811121358t49bdda16j8d2a7d9a0fbd2c30@mail.gmail.com> <492C473F.609@btinternet.com> Message-ID: <514365884.20081125222704@gmail.com> Hello Andrew, Tuesday, November 25, 2008, 9:43:11 PM, you wrote: > OOP seems like such a natural fit for describing the behaviour of a > network of independent objects. But Haskell seems to require you to make > a new, modified copy of the entire game state at each frame, which > sounds... highly non-performant. "most of the game state" is a few mb maximum. you don't need to copy textures and other permanent game object descriptors which occupies most part of those hundredths mbs just an example from my own work: i wrote an archiver which may use, say, 500 mb for storing list of million files. but the list itslef occupies only ~10mb, so i can do all the forms of complex processing without over-loading memory manager. each file descrption is 500 bytes long, but this info isn't changed during program run -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bartek at sudety.it Tue Nov 25 16:12:13 2008 From: bartek at sudety.it (Bartosz =?iso-8859-1?q?W=F3jcik?=) Date: Tue Nov 25 15:06:05 2008 Subject: [Haskell-cafe] Windows vs. Linux x64 In-Reply-To: <20081124225902.GG10286@scytale.galois.com> References: <200811250056.27632.bartek@sudety.it> <20081124225902.GG10286@scytale.galois.com> Message-ID: <200811252212.13647.bartek@sudety.it> On Monday 24 November 2008 23:59:02 Don Stewart wrote: > bartek: > > Hi Everybody, > > > > while working on my resent project I've noticed that my code seems to be > > faster under Windows than under Linux x64. > > Is Windows running in 32 bit? What gcc versions are you using on each > system? > Windows is 32 bit with GHC-6.8.3. Linux is 64 bit with GHC-6.10.1. Bartek From duncan.coutts at worc.ox.ac.uk Tue Nov 25 15:18:35 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Nov 25 15:12:27 2008 Subject: [Haskell-cafe] build tools and Cabal In-Reply-To: <9979e72e0811241730n46ee2c06p1093f654f6896bee@mail.gmail.com> References: <9979e72e0811241730n46ee2c06p1093f654f6896bee@mail.gmail.com> Message-ID: <1227644315.19577.21.camel@localhost> On Tue, 2008-11-25 at 01:30 +0000, John Lato wrote: > Hello, > > Cabal allows specifying arguments for tools it recognizes on the > command line, e.g. > > runhaskell Setup.hs configure --c2hs-option=some_option > > Unfortunately, I can't find a way to make this work with .cabal (or > .buildinfo) files, except for the specific cases of ghc, hugs, and > nhc98 options. Am I missing something? No. > If not, could this be added easily? Yes, but it's not clear that we should. > It would be very helpful as I'm trying to work around the broken cpp > Apple provides. Perhaps we should do the workaround once rather than adding the workaround to every package. What is the problem exactly? Duncan From ketil at malde.org Tue Nov 25 15:39:35 2008 From: ketil at malde.org (Ketil Malde) Date: Tue Nov 25 15:33:24 2008 Subject: [Haskell-cafe] Windows vs. Linux x64 In-Reply-To: <200811252212.13647.bartek@sudety.it> ("Bartosz =?utf-8?Q?W?= =?utf-8?Q?=C3=B3jcik=22's?= message of "Tue\, 25 Nov 2008 22\:12\:13 +0100") References: <200811250056.27632.bartek@sudety.it> <20081124225902.GG10286@scytale.galois.com> <200811252212.13647.bartek@sudety.it> Message-ID: <87myfnv8u0.fsf@malde.org> Bartosz W?jcik writes: >>> while working on my resent project I've noticed that my code seems to be >>> faster under Windows than under Linux x64. >> Is Windows running in 32 bit? What gcc versions are you using on each >> system? > Windows is 32 bit with GHC-6.8.3. > Linux is 64 bit with GHC-6.10.1. This corresponds to my experiences - 64 bits is slower, something I've ascribed to the cost of increased pointer size. -k -- If I haven't seen further, it is by standing in the footprints of giants From dons at galois.com Tue Nov 25 17:07:03 2008 From: dons at galois.com (Don Stewart) Date: Tue Nov 25 17:00:47 2008 Subject: [Haskell-cafe] Re: Problem getting code from AFP08 parallel tutorial to run in parallel In-Reply-To: References: <20081124185140.GC7952@scytale.galois.com> <492C06B4.4030401@gmail.com> Message-ID: <20081125220703.GK14812@scytale.galois.com> olivier.boudry: > On Tue, Nov 25, 2008 at 3:07 PM, Simon Marlow wrote: > > Yes, it's a scheduling bug. I'll make sure it gets fixed for 6.10.2. If > > you have more sparks then you shouldn't see this problem. Also, GHC HEAD is > > quite a lot better with parallel programs than 6.10.1, I'll try to get > > around to posting some figures sometime. > > Yes, I tried it with 3 sparks and it works, > > Thanks for your help, > What does the code look like? Simon : should we be start to try tthe HEAD for par stuff? -- Don From john at repetae.net Tue Nov 25 19:59:44 2008 From: john at repetae.net (John Meacham) Date: Tue Nov 25 19:53:28 2008 Subject: [Haskell-cafe] Data.Array.Storable vs GC In-Reply-To: <1227620728.3207.5.camel@Congo> References: <1227620728.3207.5.camel@Congo> Message-ID: <20081126005944.GA9558@sliver.repetae.net> GHC has 'pinned arrays' that have this behavior. however, you probably don't want to use them as they simply give the garbage collector less choices about what to do possibly decreasing its efficiency. The garbage collector already is free to not copy arrays if it feels it isn't worth it, by pinning them you simply take away its ability to choose to do so if it is needed. John -- John Meacham - ?repetae.net?john? From john at repetae.net Tue Nov 25 20:08:01 2008 From: john at repetae.net (John Meacham) Date: Tue Nov 25 20:01:45 2008 Subject: [Haskell-cafe] Password hashing In-Reply-To: <910ddf450811250738l667d3b4dn9cffb05fa8e10374@mail.gmail.com> References: <6205bd290810280842lc419882w80f144828b8d56cb@mail.gmail.com> <1041538055.20081028184923@gmail.com> <916b84820810291727tb2c3e0au3df64232f3636a87@mail.gmail.com> <22f6a8f70810291732k1f72fd04w8b4669ad4e75d4a1@mail.gmail.com> <910ddf450810300532l4cc15d4dn65f84faf59d23d3e@mail.gmail.com> <75960862.20081030172321@gmail.com> <910ddf450811250738l667d3b4dn9cffb05fa8e10374@mail.gmail.com> Message-ID: <20081126010801.GB9558@sliver.repetae.net> What you are using there is not a salt, but rather a secret key. The important thing about a salt is that it is different for _every user_. and you actually store the salt unhashed along with the hash. (it is not secret information). A salt protects against a dictionary attack, for instance, you might have a dictionary of hash's and the common passwords they go to but if you add a 32 bit salt, you would need 2^32 entries for each dictionary word, making such an attack unworkable. You can also trivially tell if two users have the _same_ password just by comparing the hashes without a salt. John -- John Meacham - ?repetae.net?john? From john at repetae.net Tue Nov 25 20:16:26 2008 From: john at repetae.net (John Meacham) Date: Tue Nov 25 20:10:54 2008 Subject: [Haskell-cafe] Windows vs. Linux x64 In-Reply-To: <87myfnv8u0.fsf@malde.org> References: <200811250056.27632.bartek@sudety.it> <20081124225902.GG10286@scytale.galois.com> <200811252212.13647.bartek@sudety.it> <87myfnv8u0.fsf@malde.org> Message-ID: <20081126011626.GC9558@sliver.repetae.net> On Tue, Nov 25, 2008 at 09:39:35PM +0100, Ketil Malde wrote: > This corresponds to my experiences - 64 bits is slower, something I've > ascribed to the cost of increased pointer size. ghc unfortunatly also uses 64 bit integers when in 64 bit mode, so the cost paid is increased due to that as well, Also since each math instruction needs an extra byte telling it to work on 64 bit data so the code is less dense. John -- John Meacham - ?repetae.net?john? From tphyahoo at gmail.com Tue Nov 25 20:37:12 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Tue Nov 25 20:30:56 2008 Subject: [Haskell-cafe] Password hashing In-Reply-To: <20081126010801.GB9558@sliver.repetae.net> References: <6205bd290810280842lc419882w80f144828b8d56cb@mail.gmail.com> <1041538055.20081028184923@gmail.com> <916b84820810291727tb2c3e0au3df64232f3636a87@mail.gmail.com> <22f6a8f70810291732k1f72fd04w8b4669ad4e75d4a1@mail.gmail.com> <910ddf450810300532l4cc15d4dn65f84faf59d23d3e@mail.gmail.com> <75960862.20081030172321@gmail.com> <910ddf450811250738l667d3b4dn9cffb05fa8e10374@mail.gmail.com> <20081126010801.GB9558@sliver.repetae.net> Message-ID: <910ddf450811251737j4fa5817as5e9b7d43b619257e@mail.gmail.com> OK, I went ahead and implemented pbkdf2, following the algorithm linked to by bulat and Michael. If there are any crypto gurus who can code-review this I would be much obliged, and when I'm confident enough that this does the right thing I'll put it up on hackage. I don't do much crypto so this *definitely* needs a review before it becomes a library? How's this looks, cafe? Thanks! Thomas. {-# LANGUAGE ScopedTypeVariables #-} module Crypto.PBKDF2 (pbkdf2, pbkdf2') where import qualified Data.ByteString.Char8 as B import qualified Data.ByteString.Lazy as L import GHC.Word import Control.Monad (foldM) import Random import Data.Digest.SHA512 (hash) import Data.Word import Data.Bits import Data.Binary newtype Password = Password [Word8] newtype Salt = Salt [Word8] newtype HashedPass = HashedPass [Word8] deriving Show {- | A reasonable default for rsa pbkdf2? Actually I'm not really sure, ask folk with more experience. > pbkdf2 = pbkdf2' prfSHA512 512 512 512 -} t = pbkdf2 ( Password . toWord8s $ "meh" ) ( Salt . toWord8s $ "moo" ) pbkdf2 :: Password -> Salt -> HashedPass pbkdf2 = pbkdf2' prfSHA512 512 512 512 {- | Password Based Key Derivation Function, from RSA labs. > pbkdf2' prf hlen cIters dklen (Password pass) (Salt salt) -} pbkdf2' :: ([Word8] -> [Word8] -> [Word8]) -> Integer -> Integer -> Integer -> Password -> Salt -> HashedPass pbkdf2' prf hlen cIters dklen (Password pass) (Salt salt) | dklen > ( (2^32-1) * hlen) = error $ "pbkdf2, (dklen,hlen) : " ++ (show (dklen,hlen)) | otherwise = let --l,r :: Int l = ceiling $ (fromIntegral dklen) / (fromIntegral hlen ) r = dklen - ( (l-1) * hlen) ustream :: [Word8] -> [Word8] -> [[Word8]] ustream p s = let x = prf p s in x : ustream p x --us :: Integer -> [[Word8]] us i = take (fromIntegral cIters) $ ustream pass ( salt `myor` ((intToFourWord8s i) )) --f :: [Word8] -> [Word8] -> Integer -> Integer -> [Word8] f pass salt cIters i = foldr1 myxor $ us i ts :: [[Word8]] ts = map (f pass salt cIters) ( [1..l] ) in HashedPass . take (fromIntegral dklen) . concat $ ts -- The spec says -- Here, INT (i) is a four-octet encoding of the integer i, most significant octet first. -- I'm reading from the right... is this the right thing? toWord8s x = L.unpack . encode $ x --intToFourWord8s :: Integer -> [Word8] intToFourWord8s i = let w8s = toWord8s $ i in drop (length w8s -4) w8s myxor :: [Word8] -> [Word8] -> [Word8] myxor = zipWith xor myor :: [Word8] -> [Word8] -> [Word8] myor = zipWith (.|.) prfSHA512 :: [Word8] -> [Word8] -> [Word8] prfSHA512 x y = hash $ x ++ y 2008/11/26 John Meacham : > What you are using there is not a salt, but rather a secret key. The > important thing about a salt is that it is different for _every user_. > and you actually store the salt unhashed along with the hash. (it is not > secret information). A salt protects against a dictionary attack, for > instance, you might have a dictionary of hash's and the common passwords > they go to but if you add a 32 bit salt, you would need 2^32 entries for > each dictionary word, making such an attack unworkable. You can also > trivially tell if two users have the _same_ password just by comparing > the hashes without a salt. > > John > > -- > John Meacham - ?repetae.net?john? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From tphyahoo at gmail.com Tue Nov 25 20:39:05 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Tue Nov 25 20:32:50 2008 Subject: [Haskell-cafe] Password hashing In-Reply-To: <910ddf450811251737j4fa5817as5e9b7d43b619257e@mail.gmail.com> References: <6205bd290810280842lc419882w80f144828b8d56cb@mail.gmail.com> <1041538055.20081028184923@gmail.com> <916b84820810291727tb2c3e0au3df64232f3636a87@mail.gmail.com> <22f6a8f70810291732k1f72fd04w8b4669ad4e75d4a1@mail.gmail.com> <910ddf450810300532l4cc15d4dn65f84faf59d23d3e@mail.gmail.com> <75960862.20081030172321@gmail.com> <910ddf450811250738l667d3b4dn9cffb05fa8e10374@mail.gmail.com> <20081126010801.GB9558@sliver.repetae.net> <910ddf450811251737j4fa5817as5e9b7d43b619257e@mail.gmail.com> Message-ID: <910ddf450811251739l3f297feew9848854828a30c3b@mail.gmail.com> Sorry about the hideous formatting above. Reattached as a text file. t. 2008/11/26 Thomas Hartman : > OK, I went ahead and implemented pbkdf2, following the algorithm > linked to by bulat and Michael. > > If there are any crypto gurus who can code-review this I would be much > obliged, and when I'm confident enough that this does the right thing > I'll put it up on hackage. > > I don't do much crypto so this *definitely* needs a review before it > becomes a library? > > How's this looks, cafe? > > Thanks! > > Thomas. > > > {-# LANGUAGE ScopedTypeVariables #-} > module Crypto.PBKDF2 (pbkdf2, pbkdf2') where > > import qualified Data.ByteString.Char8 as B > import qualified Data.ByteString.Lazy as L > import GHC.Word > import Control.Monad (foldM) > import Random > import Data.Digest.SHA512 (hash) > import Data.Word > import Data.Bits > import Data.Binary > > newtype Password = Password [Word8] > newtype Salt = Salt [Word8] > newtype HashedPass = HashedPass [Word8] > deriving Show > {- | A reasonable default for rsa pbkdf2? Actually I'm not really > sure, ask folk with more experience. > >> pbkdf2 = pbkdf2' prfSHA512 512 512 512 > -} > t = pbkdf2 ( Password . toWord8s $ "meh" ) ( Salt . toWord8s $ "moo" ) > pbkdf2 :: Password -> Salt -> HashedPass > pbkdf2 = pbkdf2' prfSHA512 512 512 512 > > {- | Password Based Key Derivation Function, from RSA labs. > >> pbkdf2' prf hlen cIters dklen (Password pass) (Salt salt) > -} > pbkdf2' :: ([Word8] -> [Word8] -> [Word8]) -> Integer -> Integer -> > Integer -> Password -> Salt -> HashedPass > pbkdf2' prf hlen cIters dklen (Password pass) (Salt salt) > | dklen > ( (2^32-1) * hlen) = error $ "pbkdf2, (dklen,hlen) : " ++ > (show (dklen,hlen)) > | otherwise = > let --l,r :: Int > l = ceiling $ (fromIntegral dklen) / (fromIntegral hlen ) > r = dklen - ( (l-1) * hlen) > ustream :: [Word8] -> [Word8] -> [[Word8]] > ustream p s = let x = prf p s > in x : ustream p x > --us :: Integer -> [[Word8]] > us i = take (fromIntegral cIters) $ ustream pass ( salt `myor` > ((intToFourWord8s i) )) > --f :: [Word8] -> [Word8] -> Integer -> Integer -> [Word8] > f pass salt cIters i = foldr1 myxor $ us i > ts :: [[Word8]] > ts = map (f pass salt cIters) ( [1..l] ) > in HashedPass . take (fromIntegral dklen) . concat $ ts > > -- The spec says > -- Here, INT (i) is a four-octet encoding of the integer i, most > significant octet first. > -- I'm reading from the right... is this the right thing? > toWord8s x = L.unpack . encode $ x > > --intToFourWord8s :: Integer -> [Word8] > intToFourWord8s i = let w8s = toWord8s $ i > in drop (length w8s -4) w8s > > myxor :: [Word8] -> [Word8] -> [Word8] > myxor = zipWith xor > > myor :: [Word8] -> [Word8] -> [Word8] > myor = zipWith (.|.) > > prfSHA512 :: [Word8] -> [Word8] -> [Word8] > prfSHA512 x y = hash $ x ++ y > > > 2008/11/26 John Meacham : >> What you are using there is not a salt, but rather a secret key. The >> important thing about a salt is that it is different for _every user_. >> and you actually store the salt unhashed along with the hash. (it is not >> secret information). A salt protects against a dictionary attack, for >> instance, you might have a dictionary of hash's and the common passwords >> they go to but if you add a 32 bit salt, you would need 2^32 entries for >> each dictionary word, making such an attack unworkable. You can also >> trivially tell if two users have the _same_ password just by comparing >> the hashes without a salt. >> >> John >> >> -- >> John Meacham - ?repetae.net?john? >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: PBKDF2.hs Type: text/x-haskell Size: 2308 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081126/846ff3a1/PBKDF2-0001.bin From bos at serpentine.com Wed Nov 26 00:15:54 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed Nov 26 00:09:40 2008 Subject: [Haskell-cafe] ANN: "Real World Haskell", now shipping Message-ID: Good evening - John Goerzen, Don Stewart and I are delighted to announce the availability of our book, "Real World Haskell". It is 710 pages long, and published by O'Reilly Media. This is the first book to comprehensively cover modern Haskell programming. From an introduction to functional programming, it focuses on teaching through many worked examples. We discuss the "awkward squad" of I/O, concurrency, and exceptions. We cover network programming, databases, and system hacking. We motivate and work with monoids, applicative functors, monads, and monad transformers. We show you how to debug code, and how to ship well-tested software. Better yet, the book is available under a Creative Commons license, so you can read as much of it as you please before you buy: http://book.realworldhaskell.org/ We developed this book with the enthusiastic and voluble support of the Haskell community, and we are proud to share our work in a fashion that will help newcomers to our field. And best of all, if you order now (at least in North America), you can have a copy of the book in your hands in a matter of days. Thank you from all of us to our friends in the Haskell world who have been so generous with their feedback and kind words! From vigalchin at gmail.com Wed Nov 26 01:42:04 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed Nov 26 01:35:50 2008 Subject: [Haskell-cafe] IRC question Message-ID: <5ae4f2ba0811252242o637b9704y10018221d8e50fe9@mail.gmail.com> Hello, I am using Ubuntu Linux and I want to get the Haskell IRC feed. What IRC client can I use and how to configure? Thanks, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081126/e050759f/attachment.htm From aapo at pokat.org Wed Nov 26 02:03:21 2008 From: aapo at pokat.org (Aapo Lehtinen) Date: Wed Nov 26 01:57:14 2008 Subject: [Haskell-cafe] IRC question In-Reply-To: <5ae4f2ba0811252242o637b9704y10018221d8e50fe9@mail.gmail.com> References: <5ae4f2ba0811252242o637b9704y10018221d8e50fe9@mail.gmail.com> Message-ID: <492CF4B9.5040707@pokat.org> Galchin, Vasili kirjoitti: > Hello, > > I am using Ubuntu Linux and I want to get the Haskell IRC feed. What > IRC client can I use and how to configure? > > Thanks, Vasili > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe Pidgin uses IRC-protocol, but Xchat can be found in Synaptic which is more popular client. In start-up screen of Xchat you have a list of servers where you search Freenode or add new server (closest freenode-server for you), then join new channel (F3 if I recall, or ctrl + j, or "/j #haskell" in commandline of the client). Aapo From dons at galois.com Wed Nov 26 02:04:50 2008 From: dons at galois.com (Don Stewart) Date: Wed Nov 26 01:58:37 2008 Subject: [Haskell-cafe] IRC question In-Reply-To: <492CF4B9.5040707@pokat.org> References: <5ae4f2ba0811252242o637b9704y10018221d8e50fe9@mail.gmail.com> <492CF4B9.5040707@pokat.org> Message-ID: <20081126070450.GF16373@scytale.galois.com> aapo: > Galchin, Vasili kirjoitti: > >Hello, > > > > I am using Ubuntu Linux and I want to get the Haskell IRC feed. What > >IRC client can I use and how to configure? > > > >Thanks, Vasili > > > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >Haskell-Cafe mailing list > >Haskell-Cafe@haskell.org > >http://www.haskell.org/mailman/listinfo/haskell-cafe > > Pidgin uses IRC-protocol, but Xchat can be found in Synaptic which is > more popular client. > > In start-up screen of Xchat you have a list of servers where you search > Freenode or add new server (closest freenode-server for you), then join > new channel (F3 if I recall, or ctrl + j, or "/j #haskell" in > commandline of the client). > As with all good things, preferred clients are documented on the wiki, http://haskell.org/haskellwiki/IRC_channel Cheers, Don From donnie at darthik.com Wed Nov 26 02:29:05 2008 From: donnie at darthik.com (Donnie Jones) Date: Wed Nov 26 02:22:52 2008 Subject: [Haskell-cafe] Re: [Haskell] ANN: "Real World Haskell", now shipping In-Reply-To: References: Message-ID: Mine arrives in two days; I can't wait! :) Thanks for all your hard work, and to all the members of the community which provided comments/suggestions to improve the book. __ Donnie Jones On Wed, Nov 26, 2008 at 12:15 AM, Bryan O'Sullivan wrote: > Good evening - > > John Goerzen, Don Stewart and I are delighted to announce the > availability of our book, "Real World Haskell". It is 710 pages long, > and published by O'Reilly Media. > > This is the first book to comprehensively cover modern Haskell > programming. From an introduction to functional programming, it > focuses on teaching through many worked examples. We discuss the > "awkward squad" of I/O, concurrency, and exceptions. We cover network > programming, databases, and system hacking. We motivate and work with > monoids, applicative functors, monads, and monad transformers. We show > you how to debug code, and how to ship well-tested software. > > Better yet, the book is available under a Creative Commons license, so > you can read as much of it as you please before you buy: > http://book.realworldhaskell.org/ We developed this book with the > enthusiastic and voluble support of the Haskell community, and we are > proud to share our work in a fashion that will help newcomers to our > field. > > And best of all, if you order now (at least in North America), you can > have a copy of the book in your hands in a matter of days. > > Thank you from all of us to our friends in the Haskell world who have > been so generous with their feedback and kind words! > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081126/c4eac90b/attachment.htm From dagit at codersbase.com Wed Nov 26 02:48:30 2008 From: dagit at codersbase.com (Jason Dagit) Date: Wed Nov 26 02:42:14 2008 Subject: [Haskell-cafe] IRC question In-Reply-To: <20081126070450.GF16373@scytale.galois.com> References: <5ae4f2ba0811252242o637b9704y10018221d8e50fe9@mail.gmail.com> <492CF4B9.5040707@pokat.org> <20081126070450.GF16373@scytale.galois.com> Message-ID: On Tue, Nov 25, 2008 at 11:04 PM, Don Stewart wrote: > aapo: > > Galchin, Vasili kirjoitti: > > >Hello, > > > > > > I am using Ubuntu Linux and I want to get the Haskell IRC feed. What > > >IRC client can I use and how to configure? > > > > > >Thanks, Vasili > > > > > > > > >------------------------------------------------------------------------ > > > > > >_______________________________________________ > > >Haskell-Cafe mailing list > > >Haskell-Cafe@haskell.org > > >http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > Pidgin uses IRC-protocol, but Xchat can be found in Synaptic which is > > more popular client. > > > > In start-up screen of Xchat you have a list of servers where you search > > Freenode or add new server (closest freenode-server for you), then join > > new channel (F3 if I recall, or ctrl + j, or "/j #haskell" in > > commandline of the client). > > > > As with all good things, preferred clients are documented on the wiki, > > http://haskell.org/haskellwiki/IRC_channel Sadly none of the recommended clients are written in Haskell or extensible in Haskell. Two of the recommended clients on that page are ERC (an emacs client) and irssi (highly scriptable in perl). I used ERC for several years and developed a good deal of extension code and customizations for it as I found things that worked and didn't work for me. Eventually I was forced to move to irssi due to the horrible resource usage of ERC that plagued me despite spending considerable time debugging it. Being a perl illiterate, I'm always sad I can't extend my IRC client now. Does anyone have an IRC client hiding somewhere that is console friendly (I IRC from a screen session) which is also extensible in Haskell? Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081125/8c866ef4/attachment.htm From dav.vire+haskell at gmail.com Wed Nov 26 03:08:51 2008 From: dav.vire+haskell at gmail.com (david48) Date: Wed Nov 26 03:02:35 2008 Subject: [Haskell-cafe] Re: [Haskell] ANN: "Real World Haskell", now shipping In-Reply-To: References: Message-ID: <4c88418c0811260008g360de494s443ad861032c3a24@mail.gmail.com> Is it possible to order it from France yet ? From dons at galois.com Wed Nov 26 03:10:59 2008 From: dons at galois.com (Don Stewart) Date: Wed Nov 26 03:04:42 2008 Subject: [Haskell-cafe] Re: [Haskell] ANN: "Real World Haskell", now shipping In-Reply-To: <4c88418c0811260008g360de494s443ad861032c3a24@mail.gmail.com> References: <4c88418c0811260008g360de494s443ad861032c3a24@mail.gmail.com> Message-ID: <20081126081059.GG16373@scytale.galois.com> dav.vire+haskell: > Is it possible to order it from France yet ? http://www.amazon.fr/Real-World-Haskell-Bryan-OSullivan/dp/0596514980/ref=sr_1_1?ie=UTF8&s=english-books&qid=1227687031&sr=8-1 ? From dav.vire+haskell at gmail.com Wed Nov 26 03:17:31 2008 From: dav.vire+haskell at gmail.com (david48) Date: Wed Nov 26 03:11:18 2008 Subject: [Haskell-cafe] Re: [Haskell] ANN: "Real World Haskell", now shipping In-Reply-To: <20081126081059.GG16373@scytale.galois.com> References: <4c88418c0811260008g360de494s443ad861032c3a24@mail.gmail.com> <20081126081059.GG16373@scytale.galois.com> Message-ID: <4c88418c0811260017v465f8ffaq3beb080c560bdfb2@mail.gmail.com> On Wed, Nov 26, 2008 at 9:10 AM, Don Stewart wrote: > dav.vire+haskell: >> Is it possible to order it from France yet ? > > http://www.amazon.fr/Real-World-Haskell-Bryan-OSullivan/dp/0596514980/ref=sr_1_1?ie=UTF8&s=english-books&qid=1227687031&sr=8-1 > Actually right now I was logging in to Amazon.fr to check :) Thanks. I'm going to order 3 copies and offer 2 for christmas. From dav.vire+haskell at gmail.com Wed Nov 26 03:31:54 2008 From: dav.vire+haskell at gmail.com (david48) Date: Wed Nov 26 03:25:37 2008 Subject: [Haskell-cafe] Re: [Haskell] ANN: "Real World Haskell", now shipping In-Reply-To: <4c88418c0811260017v465f8ffaq3beb080c560bdfb2@mail.gmail.com> References: <4c88418c0811260008g360de494s443ad861032c3a24@mail.gmail.com> <20081126081059.GG16373@scytale.galois.com> <4c88418c0811260017v465f8ffaq3beb080c560bdfb2@mail.gmail.com> Message-ID: <4c88418c0811260031s58764639j2a23d90d8ddde004@mail.gmail.com> > Actually right now I was logging in to Amazon.fr to check :) It's not available yet on Amazon.fr. I've ordered them anyway, but I'm warned that I will not have them for christmas :( From nicolas.pouillard at gmail.com Wed Nov 26 03:40:54 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Wed Nov 26 03:35:35 2008 Subject: [Haskell-cafe] Re: [Haskell] ANN: "Real World Haskell", now shipping In-Reply-To: <4c88418c0811260031s58764639j2a23d90d8ddde004@mail.gmail.com> References: <4c88418c0811260008g360de494s443ad861032c3a24@mail.gmail.com> <20081126081059.GG16373@scytale.galois.com> <4c88418c0811260017v465f8ffaq3beb080c560bdfb2@mail.gmail.com> <4c88418c0811260031s58764639j2a23d90d8ddde004@mail.gmail.com> Message-ID: <1227688806-sup-3527@ausone.inria.fr> Excerpts from david48's message of Wed Nov 26 09:31:54 +0100 2008: > > Actually right now I was logging in to Amazon.fr to check :) > > It's not available yet on Amazon.fr. I've ordered them anyway, but I'm > warned that I will not have them for christmas :( I've ordered it on Amazon.fr some months ago and it's planned for the 10 December. -- Nicolas Pouillard aka Ertai From marlowsd at gmail.com Wed Nov 26 04:13:53 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 26 04:07:44 2008 Subject: [Haskell-cafe] Re: Problem getting code from AFP08 parallel tutorial to run in parallel In-Reply-To: <20081125220703.GK14812@scytale.galois.com> References: <20081124185140.GC7952@scytale.galois.com> <492C06B4.4030401@gmail.com> <20081125220703.GK14812@scytale.galois.com> Message-ID: <492D1351.2070703@gmail.com> Don Stewart wrote: > olivier.boudry: >> On Tue, Nov 25, 2008 at 3:07 PM, Simon Marlow wrote: >>> Yes, it's a scheduling bug. I'll make sure it gets fixed for 6.10.2. If >>> you have more sparks then you shouldn't see this problem. Also, GHC HEAD is >>> quite a lot better with parallel programs than 6.10.1, I'll try to get >>> around to posting some figures sometime. >> Yes, I tried it with 3 sparks and it works, >> >> Thanks for your help, >> > > What does the code look like? > > Simon : should we be start to try tthe HEAD for par stuff? Please do - also I'm on the lookout for good benchmarks to add to nofib/parallel. Particularly programs that you think should speed up in parallel but don't - sometimes that helps us find bottlenecks in the runtime. Cheers, Simon From jeffzaroyko at gmail.com Wed Nov 26 07:19:45 2008 From: jeffzaroyko at gmail.com (Jeff Zaroyko) Date: Wed Nov 26 07:13:30 2008 Subject: [Haskell-cafe] IRC question In-Reply-To: <5ae4f2ba0811252242o637b9704y10018221d8e50fe9@mail.gmail.com> References: <5ae4f2ba0811252242o637b9704y10018221d8e50fe9@mail.gmail.com> Message-ID: 2008/11/26 Galchin, Vasili : > Hello, > > I am using Ubuntu Linux and I want to get the Haskell IRC feed. What IRC > client can I use and how to configure? > > Thanks, Vasili > If you are an Emacs user, then you can either use rcirc or erc M-x erc RET RET RET RET /join #haskell RET -Jeff From leimy2k at gmail.com Wed Nov 26 08:43:36 2008 From: leimy2k at gmail.com (David Leimbach) Date: Wed Nov 26 08:37:21 2008 Subject: [Haskell-cafe] Re: [Haskell] ANN: "Real World Haskell", now shipping In-Reply-To: References: Message-ID: <3e1162e60811260543w542d8d04o32d566f5835d2955@mail.gmail.com> Very excited to receive my copy! Congrats to the 3 of you! On Tue, Nov 25, 2008 at 9:15 PM, Bryan O'Sullivan wrote: > Good evening - > > John Goerzen, Don Stewart and I are delighted to announce the > availability of our book, "Real World Haskell". It is 710 pages long, > and published by O'Reilly Media. > > This is the first book to comprehensively cover modern Haskell > programming. From an introduction to functional programming, it > focuses on teaching through many worked examples. We discuss the > "awkward squad" of I/O, concurrency, and exceptions. We cover network > programming, databases, and system hacking. We motivate and work with > monoids, applicative functors, monads, and monad transformers. We show > you how to debug code, and how to ship well-tested software. > > Better yet, the book is available under a Creative Commons license, so > you can read as much of it as you please before you buy: > http://book.realworldhaskell.org/ We developed this book with the > enthusiastic and voluble support of the Haskell community, and we are > proud to share our work in a fashion that will help newcomers to our > field. > > And best of all, if you order now (at least in North America), you can > have a copy of the book in your hands in a matter of days. > > Thank you from all of us to our friends in the Haskell world who have > been so generous with their feedback and kind words! > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081126/2ace45dc/attachment.htm From mad.one at gmail.com Wed Nov 26 08:55:56 2008 From: mad.one at gmail.com (Austin Seipp) Date: Wed Nov 26 08:49:41 2008 Subject: [Haskell-cafe] IRC question In-Reply-To: References: <5ae4f2ba0811252242o637b9704y10018221d8e50fe9@mail.gmail.com> <492CF4B9.5040707@pokat.org> <20081126070450.GF16373@scytale.galois.com> Message-ID: <1227706641-sup-2733@existential.local> > Does anyone have an IRC client hiding somewhere that is console friendly (I > IRC from a screen session) which is also extensible in Haskell? > http://www.haskell.org/hircules/ Last update was over 5 years ago - you could try to still build it. But it uses gtk2hs, not ncurses. Personally, I've thought about this as a project *several* times in the past, and somewhere around here, I might have a few bits of code thrown together laying around. The -main- reasons I haven't worked on it any more than I have already is because: A) I was under the impression I was still the only one looking for something like this - or maybe lots of people want an 'xmonad equivilant' of their IRC Client? :) B) My uni. blocks 6667 for some reason, so in order to connect with a terminal IRC client outside of here, I need to use SSL. And there are *no* good SSL wrappers out there at all for Haskell as it stands - this alone is a major inhibitor of usage; I know I always want my clients with SSL support. C) I've been busy. That said, if you would like to really get something started and perhaps hack on some stuff, that would be terrifically fun and interesting. Does anybody have name candidates? Perhaps we should go with the yi scheme from confucianism - the zhi (knowledge) IRC client? ;) > Thanks, > Jason Austin From kowey at darcs.net Wed Nov 26 09:38:33 2008 From: kowey at darcs.net (Eric Kow) Date: Wed Nov 26 09:32:21 2008 Subject: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs Message-ID: <20081126143832.GC15463@brighton.ac.uk> Hi everybody, This advisory is for people who have installed darcs 2.1.2 via the Cabal build method. As you may have noticed, the cabalised darcs sometimes fails with errors like Codec.Compression.Zlib: incorrect data check Why this happens ---------------- Older versions of darcs can to produce gzipped files with broken CRCs. We never noticed this because our homegrown wrapper around the C libz library does not pick up these errors. Lately, we have been working on adopting the Haskell zlib wrapper, which is made available by default in darcs.cabal. This new wrapper is more stringent and fails when it encounters these files. Workaround 1 : use C libz instead of Haskell zlib ------------------------------------------------- So how can you work around these errors? If you are building darcs on any Unix-y operating system (e.g. Linux or MacOS X), you can cabal configure darcs to use the old C libz binding: cabal configure -f external-zlib This will restore our homegrown wrapper which ignores the broken CRCs (note that the darcs head no longer *produces* these broken files, thanks to debugging by Matthias Andree and to a bugfix by David Roundy; http://bugs.darcs.net/issue844 for details). In principle, the same advice applies for Windows users, with more details hopefully to follow on how the C libz in a GHC-accesible location. Details to follow. In the meantime, you can either build darcs using the old configure and make technique (assuming you have MSYS and related tools), or use a binary that does not use the Haskell zlib wrapper (for example, by downgrading to http://www.haskell.org/~simonmar/darcs-2.0.2+75.zip ) Workaround 2 : fix your broken gzipped files -------------------------------------------- If you have control over the repositories with broken gzipped files, it should be possible to repair these files by gunzipping them and then redo-ing the gzip. We think that the attached script should help. Please report back if this is not the case. How we will fix this problem in the long term --------------------------------------------- I'm very sorry for the grief this has caused. To begin with, we will ensure that the 2.2 release gets more testing before releasing it in January. It will also handle these broken CRCs more gracefully. Our plan is to - either extend darcs repair or provide a Haskell script to fix these broken files - detect the broken files and advise users to run darcs repair (or the script) as needed - somewhere in the future, disallow broken CRC files whilst still advising users on how to fix their files. Many thanks! -- Eric Kow PGP Key ID: 08AC04F9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081126/9ff3c2aa/attachment.bin From kowey at darcs.net Wed Nov 26 09:39:39 2008 From: kowey at darcs.net (Eric Kow) Date: Wed Nov 26 09:33:30 2008 Subject: [Haskell-cafe] Re: workarounds for Codec.Compression.Zlib errors in darcs In-Reply-To: <20081126143832.GC15463@brighton.ac.uk> References: <20081126143832.GC15463@brighton.ac.uk> Message-ID: <20081126143938.GD15463@brighton.ac.uk> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081126/426d909d/attachment.bin From simonpj at microsoft.com Wed Nov 26 10:45:06 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Nov 26 10:38:52 2008 Subject: [Haskell-cafe] template haskell overly conservative during splicing? In-Reply-To: <5ce89fb50811031702x66936740v6eeb6d49b4cc29a7@mail.gmail.com> References: <5ce89fb50811031702x66936740v6eeb6d49b4cc29a7@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C331980121C8@EA-EXMSG-C334.europe.corp.microsoft.com> Thanks for the bug report. I've fixed the bug: see http://hackage.haskell.org/trac/ghc/ticket/2817 Simon | -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Nicolas Frisby | Sent: 04 November 2008 01:03 | To: haskell Cafe | Subject: [Haskell-cafe] template haskell overly conservative during splicing? | | When using template haskell (via Derive) to generate this (exact) instance: | | instance Foldable ((->) Int) => Foldable | Data.Derivable.InterpreterLib.Test.List | where foldMap f (Cons x0 x1) = (const mempty Cons `mappend` | foldMap f x0) `mappend` foldMap f x1 | foldMap f (Nil) = const mempty Nil | | I realize the context is insatisfiable. My issue, is that I can't even | reach that "challenge". I get this error instead: | | Malformed type AppT ArrowT (ConT GHC.Base.Int) | When splicing generated code into the program | | I couldn't find an existing ticket or discussion for this issue | relying on the phrase "malformed type". I couldn't even find the | source that generates that string in haskell-src, template-haskell, or | ghc-6.8.2. Can anybody help? | | Thanks for your time. | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe From dons at galois.com Wed Nov 26 12:11:34 2008 From: dons at galois.com (Don Stewart) Date: Wed Nov 26 12:05:17 2008 Subject: [Haskell-cafe] Re: [Haskell] ANN: "Real World Haskell", now shipping In-Reply-To: References: Message-ID: <20081126171134.GC18426@scytale.galois.com> I'd love it if people took a photo of the book arriving. With enough photos , I could put together a gallery of Haskell around the world :-) Here's my copy arriving last night, http://www.realworldhaskell.org/blog/2008/11/25/real-world-haskell-is-shipping/ And Dino's digital version, http://galois.com/~dons/images/20081121_dm_838.jpg Drop me a line with a photo of yours arriving, and your location, and I'll add it to the gallery. Cheers, Don donnie: > Mine arrives in two days; I can't wait! :) > > Thanks for all your hard work, and to all the members of the community > which provided comments/suggestions to improve the book. > __ > Donnie Jones > > On Wed, Nov 26, 2008 at 12:15 AM, Bryan O'Sullivan <[1]bos@serpentine.com> > wrote: > > Good evening - > > John Goerzen, Don Stewart and I are delighted to announce the > availability of our book, "Real World Haskell". It is 710 pages long, > and published by O'Reilly Media. > > This is the first book to comprehensively cover modern Haskell > programming. From an introduction to functional programming, it > focuses on teaching through many worked examples. We discuss the > "awkward squad" of I/O, concurrency, and exceptions. We cover network > programming, databases, and system hacking. We motivate and work with > monoids, applicative functors, monads, and monad transformers. We show > you how to debug code, and how to ship well-tested software. > > Better yet, the book is available under a Creative Commons license, so > you can read as much of it as you please before you buy: > [2]http://book.realworldhaskell.org/ We developed this book with the > enthusiastic and voluble support of the Haskell community, and we are > proud to share our work in a fashion that will help newcomers to our > field. > > And best of all, if you order now (at least in North America), you can > have a copy of the book in your hands in a matter of days. > > Thank you from all of us to our friends in the Haskell world who have > been so generous with their feedback and kind words! > _______________________________________________ > Haskell mailing list > [3]Haskell@haskell.org > [4]http://www.haskell.org/mailman/listinfo/haskell > > References > > Visible links > 1. mailto:bos@serpentine.com > 2. http://book.realworldhaskell.org/ > 3. mailto:Haskell@haskell.org > 4. http://www.haskell.org/mailman/listinfo/haskell > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From jules at jellybean.co.uk Wed Nov 26 14:09:28 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Nov 26 14:03:10 2008 Subject: [Haskell-cafe] monads with take-out options In-Reply-To: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com> References: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com> Message-ID: <492D9EE8.1020008@jellybean.co.uk> Greg Meredith wrote: > Haskellians, > > Some monads come with take-out options, e.g. > > * List > * Set > > In the sense that if unit : A -> List A is given by unit a = [a], then > taking the head of a list can be used to retrieve values from inside the > monad. > > Some monads do not come with take-out options, IO being a notorious example. > > Some monads, like Maybe, sit on the fence about take-out. They'll > provide it when it's available. To amplify other people's comments: List A is just as on the fence as Maybe. "[]" plays the role of "Nothing". Some monads require that you put something in, before you take anything out [r -> a, s -> (a,s), known to their friends as reader and state] Error is similar to Maybe, but with a more informative Nothing. Most monads provide some kind of runM :: ## -> m a -> ## a where the ## are meta-syntax, indicating that you might need to pass something in, and you might get something slightly 'funny' out. Something based upon 'a' but not entirely 'a'. The taxonomy of monads is pretty much expressed in the types of these 'run' functions, I think. Jules From jonathanccast at fastmail.fm Wed Nov 26 14:16:53 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Nov 26 14:10:41 2008 Subject: [Haskell-cafe] monads with take-out options In-Reply-To: <492D9EE8.1020008@jellybean.co.uk> References: <5de3f5ca0811241406s28362759pbc01db54147f6c4f@mail.gmail.com> <492D9EE8.1020008@jellybean.co.uk> Message-ID: <1227727014.19698.2.camel@jcchost> On Wed, 2008-11-26 at 19:09 +0000, Jules Bean wrote: > Greg Meredith wrote: > > Haskellians, > > > > Some monads come with take-out options, e.g. > > > > * List > > * Set > > > > In the sense that if unit : A -> List A is given by unit a = [a], then > > taking the head of a list can be used to retrieve values from inside the > > monad. > > > > Some monads do not come with take-out options, IO being a notorious example. > > > > Some monads, like Maybe, sit on the fence about take-out. They'll > > provide it when it's available. > > To amplify other people's comments: > > List A is just as on the fence as Maybe. "[]" plays the role of "Nothing". > > Some monads require that you put something in, before you take anything > out [r -> a, s -> (a,s), known to their friends as reader and state] > > Error is similar to Maybe, but with a more informative Nothing. > > Most monads provide some kind of > > runM :: ## -> m a -> ## a More precisely, runM :: f (m a) -> g a Where f and g are usually functors. Maybe, of course, has the nice property that g = m. jcc From bartek at sudety.it Wed Nov 26 15:20:30 2008 From: bartek at sudety.it (Bartosz =?utf-8?q?W=C3=B3jcik?=) Date: Wed Nov 26 14:14:21 2008 Subject: [Haskell-cafe] Windows vs. Linux x64 In-Reply-To: <20081126011626.GC9558@sliver.repetae.net> References: <200811250056.27632.bartek@sudety.it> <87myfnv8u0.fsf@malde.org> <20081126011626.GC9558@sliver.repetae.net> Message-ID: <200811262120.31017.bartek@sudety.it> On Wednesday 26 November 2008 02:16:26 John Meacham wrote: > On Tue, Nov 25, 2008 at 09:39:35PM +0100, Ketil Malde wrote: > > This corresponds to my experiences - 64 bits is slower, something I've > > ascribed to the cost of increased pointer size. > > ghc unfortunatly also uses 64 bit integers when in 64 bit mode, so the > cost paid is increased due to that as well, Also since each math > instruction needs an extra byte telling it to work on 64 bit data so the > code is less dense. > I've done little exeriment to confirm this. Created simple pgm and ran it with +RTS -s option on couple different harware&OS configurations. main = (putStrLn . show . head . drop 500000) prim divides d n = rem n d == 0 ldf' :: (Integral a) => [a] -> a -> a ldf' (k:ks) n | divides k n = k | k^2 > n = n | otherwise = ldf' ks n prim = filter (\x -> ldf' (2:prim) x == x) [3..] Results of experiment: Win32 Core2Duo 1.8GHz 1GB RAM 17 Mb total memory in use MUT time 56.97s ( 57.02s elapsed) %GC time 0.5% Win32 Core2Duo 2.2GHz 2GB RAM 17 Mb total memory in use MUT time 57.44s ( 57.53s elapsed) %GC time 0.7% (0.8% elapsed) Win32 P4 2.8GHz 1GB RAM 17 Mb total memory in use MUT time 171.64s (175.78s elapsed) %GC time 1.7% (1.5% elapsed) Linux64 Core2Duo 2.2GHz 2GB RAM 41 MB total memory in use (1 MB lost due to fragmentation) MUT time 68.26s ( 68.92s elapsed) %GC time 0.9% (1.1% elapsed) Linux32 Core2Duo 2.3GHz 4GB RAM 17 Mb total memory in use ? MUT ? time ? 51.77s ?( 51.83s elapsed) ? %GC time ? ? ? 0.5% ?(0.6% elapsed) Experiment confirms your explanations. Also interesting how slow P4 is in comparison to C2D. Best and thanks. Bartek From isaacdupree at charter.net Wed Nov 26 14:41:15 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Nov 26 14:34:59 2008 Subject: [Haskell-cafe] Re: [Haskell] Wait for *either* MVar to be set In-Reply-To: References: Message-ID: <492DA65B.10305@charter.net> Peter Verswyvelen wrote: > ... by spawning and killing two threads (which might be an expensive operation, I'm not sure) pretty cheap in GHC -- they're not system threads > Am I wrong in this? If so, is this something that might be considered as a future enhancement in the GHC libraries and runtime? Also, look at STM (e.g. TVars), which is designed to do what you want more directly, I think. (timeouts might still use the GHC-thread thing. Don't worry about its performance unless you're measurably suffering from it...) -Isaac From kowey at darcs.net Wed Nov 26 14:55:35 2008 From: kowey at darcs.net (Eric Kow) Date: Wed Nov 26 14:49:18 2008 Subject: [Haskell-cafe] Re: workarounds for Codec.Compression.Zlib errors in darcs In-Reply-To: <20081126143832.GC15463@brighton.ac.uk> References: <20081126143832.GC15463@brighton.ac.uk> Message-ID: <20081126195534.GB17011@brighton.ac.uk> On Wed, Nov 26, 2008 at 14:38:32 +0000, Eric Kow wrote: > Workaround 1 : use C libz instead of Haskell zlib > ------------------------------------------------- > So how can you work around these errors? If you are building darcs on > any Unix-y operating system (e.g. Linux or MacOS X), you can cabal > configure darcs to use the old C libz binding: > > cabal configure -f external-zlib My advice here is incorrect. We want the /opposite/ cabal configure -f -external-zlib Although note that a new version of darcs 2.1.2.3 will be soon on hackage with the new default (unfortunately this makes darcs a bit harder to build on Windows unless you're willing to use Workaround #2 of actually fixing your .gz files) -- Eric Kow PGP Key ID: 08AC04F9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081126/96a8cfe5/attachment.bin From paul at cogito.org.uk Wed Nov 26 15:05:40 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Wed Nov 26 14:59:40 2008 Subject: [Haskell-cafe] Instances that shouldn't overlap Message-ID: <492DAC14.5030309@cogito.org.uk> Hi, I'm trying to set up some operators for applicative versions of prelude types. For instance: -- | Applicative Equality. class (Eq a) => AppEq f a where (.==.), (./=.) :: f a -> f a -> f Bool instance (Applicative f, Eq a) => AppEq f a where (.==.) = liftA2 (==) (./=.) = liftA2 (/=) Hopefully the intention is fairly straightforward: if "f" is an instance of Applicative then the lifted implementation of the underlying type. Otherwise I can just give my own instance, which is useful for things that "wrap" prelude types but where "fmap" doesn't work. For instance: data (Ord a) => Interval a = Interval a a instance (Ord a) => AppEq Interval a where i1@(Interval _ u1) .==. i2@(Interval _ u2) | isSingleton i1 && isSingleton i2 && u1 == u2 = Interval True True | has i1 u2 || has i2 u1 = Interval False True | otherwise = Interval False False i1 ./=. i2 = let Interval b1 b2 = (i1 .==. i2) in Interval (not b2) (not b1) isSingleton :: (Ord a) => Interval a -> Bool isSingleton (Interval lower upper) = lower == upper has :: (Ord a) => Interval a -> a -> Bool has (Interval lower upper) v = v >= lower && v <= upper You can't (easily) define fmap for Interval because the function given as an argument might not be monotonic. So instead you have to write custom implementations for each lifted function, as shown here for (.==.) and (./=.) . The same principle works for AppOrd, AppNum etc, but I'm trying to solve the problem for just AppEq for now. This compiles, but when I try to use it I get this in ghci: *Interval> let i1 = Interval 4 5 *Interval> let i2 = Interval 4 6 *Interval> i1 .==. i2 :1:0: Overlapping instances for AppEq Interval Integer arising from a use of `.==.' at :1:0-9 Matching instances: instance (Ord a) => AppEq Interval a -- Defined at Interval.hs:(22,0)-(27,78) instance (Control.Applicative.Applicative f, Eq a) => AppEq f a -- Defined at AppPrelude.hs:(32,0)-(34,23) In the expression: i1 .==. i2 In the definition of `it': it = i1 .==. i2 I'm puzzled, because Interval is not an instance of Applicative, so the second instance doesn't apply. Can anyone help me out? I'm using ghc 6.8.3, so its possible that this was a bug fixed in 6.10. Paul. From paul at cogito.org.uk Wed Nov 26 15:21:26 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Wed Nov 26 15:15:11 2008 Subject: [Haskell-cafe] Instances that shouldn't overlap In-Reply-To: <492DAC14.5030309@cogito.org.uk> References: <492DAC14.5030309@cogito.org.uk> Message-ID: <492DAFC6.1040109@cogito.org.uk> Paul Johnson wrote: > Hi, > > I'm trying to set up some operators for applicative versions of > prelude types. I forgot to mention, I'm using {-# OPTIONS_GHC -fallow-undecidable-instances -XFlexibleInstances -XMultiParamTypeClasses #-} Paul. From andrewcoppin at btinternet.com Wed Nov 26 16:24:46 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Nov 26 16:18:29 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <20081124042513.GA23604@scytale.galois.com> References: <20081124042513.GA23604@scytale.galois.com> Message-ID: <492DBE9E.70701@btinternet.com> Don Stewart wrote: > Noteworthy, > > * lhc-20081121: ?Lhc Haskell Compiler? > Interesting. I can't find out any information about this... From time to time you do hear about Haskell compilers that aren't GHC, but I'm not aware of any other compilers that are production-grade yet. Has anybody ever made one? (Hugs is the only one I know of...) From ryani.spam at gmail.com Wed Nov 26 16:25:04 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Nov 26 16:18:49 2008 Subject: [Haskell-cafe] Re: [Haskell] Wait for *either* MVar to be set In-Reply-To: <492DA65B.10305@charter.net> References: <492DA65B.10305@charter.net> Message-ID: <2f9b2d30811261325q4c2d1949v1d8870ec9a192629@mail.gmail.com> In fact: > import Control.Concurrent.STM > import Control.Concurrent.STM.TMVar > -- gets a value from one of a list of TMVars > takeTMVars :: [TMVar a] -> STM (TMVar a, a) > takeTMVars = foldr fetch retry where > fetch v act = (takeTMVar v >>= \a -> return (v, a)) `orElse` act > -- puts the given value into exactly one of a list of TMVars > putTMVars :: [TMVar a] -> a -> STM (TMVar a) > putTMVars vs a = foldr put retry vs where > put v act = (putTMVar v a >> return v) `orElse` act -- ryan On Wed, Nov 26, 2008 at 11:41 AM, Isaac Dupree wrote: > Peter Verswyvelen wrote: >> >> ... by spawning and killing two threads (which might be an expensive >> operation, I'm not sure) > > pretty cheap in GHC -- they're not system threads > >> Am I wrong in this? If so, is this something that might be considered as a >> future enhancement in the GHC libraries and runtime? > > Also, look at STM (e.g. TVars), which is designed to do what you want more > directly, I think. > > (timeouts might still use the GHC-thread thing. Don't worry about its > performance unless you're measurably suffering from it...) > > -Isaac > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jake at pikewerks.com Wed Nov 26 16:29:43 2008 From: jake at pikewerks.com (Jake McArthur) Date: Wed Nov 26 16:23:43 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <492DBE9E.70701@btinternet.com> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> Message-ID: <492DBFC7.20602@pikewerks.com> Andrew Coppin wrote: > Don Stewart wrote: >> Noteworthy, >> * lhc-20081121: ?Lhc Haskell Compiler? >> > > Interesting. I can't find out any information about this... It is a fork of the JHC compiler, which should be easier to look up. There is also Hugs, as you mentioned. In addition, you may want to look at YHC and NHC. - Jake -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081126/b0ae200d/signature.bin From donnie at darthik.com Wed Nov 26 16:33:59 2008 From: donnie at darthik.com (Donnie Jones) Date: Wed Nov 26 16:27:44 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <492DBE9E.70701@btinternet.com> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> Message-ID: Hello Andrew, On Wed, Nov 26, 2008 at 4:24 PM, Andrew Coppin wrote: > Don Stewart wrote: > >> Noteworthy, >> * lhc-20081121: "Lhc Haskell Compiler" >> >> > > Interesting. I can't find out any information about this... > > Here is the current homepage for the LHC project: http://lhc.seize.it/ Hope that helps. __ Donnie Jones -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081126/5b65c388/attachment.htm From andrewcoppin at btinternet.com Wed Nov 26 16:35:01 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Nov 26 16:28:45 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <492DBFC7.20602@pikewerks.com> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DBFC7.20602@pikewerks.com> Message-ID: <492DC105.5010803@btinternet.com> Jake McArthur wrote: > Andrew Coppin wrote: >> Don Stewart wrote: >>> Noteworthy, >>> * lhc-20081121: ?Lhc Haskell Compiler? >>> >> >> Interesting. I can't find out any information about this... > > It is a fork of the JHC compiler, which should be easier to look up. > There is also Hugs, as you mentioned. In addition, you may want to > look at YHC and NHC. Yeah, the "implementations" page on the Wiki basically says that there's GHC and Hugs, and there's also these things called YHC, NHC and JHC. All the documentation I've read makes these latter compilers sound highly experimental and unusable. (I don't recall specifically which of them, but I remember hearing it can't even compile the Prelude yet.) They seem like small projects which are probably interesting to hack with, but not much use if you're trying to produce production-grade compiled code to give to a customer... OTOH, I haven't ever attempted to *use* any of these compilers. I only read about them... From andrewcoppin at btinternet.com Wed Nov 26 16:36:46 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Nov 26 16:30:27 2008 Subject: [Haskell-cafe] ANN: "Real World Haskell", now shipping In-Reply-To: References: Message-ID: <492DC16E.8050606@btinternet.com> Bryan O'Sullivan wrote: > Good evening - > > John Goerzen, Don Stewart and I are delighted to announce the > availability of our book, "Real World Haskell". It is 710 pages long, > and published by O'Reilly Media. > You know, I *was* going to rush out and buy this as soon as it hit the shelves. I was really excited that this book was actually being made, etc. But then I sat and read some of it online, and the more I read it, the more I didn't like it. :-( That sounds horribly negative when these guys have just spend I don't know *how* long perfecting the thing, and I feel like I ought to say something positive as well to make it sound less harsh. But... it all seemed a bit muddled to me. I thought chapter 1 was very strong, and the rest seemed to ramble from topic to topic. I was left feeling kinda disapointed. Then again, one day I sat down and tried to draw a diagram of the essential concepts, techniques and syntax of Haskell and how they're related... The result looked like alphabet soup! It's not clear how you start to explain anything without immediately needing to explain 20 other things you just used to explain the first thing. (Somebody commented "recursive tutorials for a recursive language". It was meant as an insult, but I actually kinda like it...) Given that that's the case, I'm not really sure that I could do any better than the Three Kings, so maybe I should just shuffle off and keep my comments to myself. :-/ What I *haven't* done yet is read the chapters where they try to claim that database programming is possible in Haskell. I'll have to do that at some point. Maybe this is where they reveal the Secret Formula that makes this stuff actually work properly... but somehow I doubt it. From ryani.spam at gmail.com Wed Nov 26 16:39:47 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Nov 26 16:33:31 2008 Subject: [Haskell-cafe] Instances that shouldn't overlap In-Reply-To: <492DAC14.5030309@cogito.org.uk> References: <492DAC14.5030309@cogito.org.uk> Message-ID: <2f9b2d30811261339o515e8ac8x5a4cda25d4b8fb65@mail.gmail.com> A common mistake (and a confusing bit about typeclasses) is that whether or not the constraints on an instance apply are irrelevant. Specifically, the code "instance (Applicative f, Eq a) => AppEq f a" means that, given any types f and a, I can tell you how to make them an instance of AppEq. But I also ask you to please add the constraints "Applicative f" and "Eq a". That is to say, only the stuff on the right of the => apply when determining whether an instance applies. If you take out the overlapping specific instance for Interval, the compiler will give you a different error: "No instance for Applicative Interval". You can see what happened here: the compiler wants an instance for AppEq Interval Integer. It sees the instance "AppEq f a" and adds the constraints "Ord Integer" and "Applicative Interval". Ord Integer is already fulfilled, but it can't discharge the constraint on Applicative, so the compile fails. Similarily, in your case, the compiler can't decide whether to apply the "Ord a => AppEq Interval a" instance, or the "Applicative f, Eq a => AppEq f a" instance; the right hand sides of the instance declarations both match (and add different constraints to the left hand side). You can use -XOverlappingInstances, but beware, dragons lie in that direction. I think this is a fundamental weakness of the typeclass system, but I haven't seen a design that avoids it for code as complicated as this. On Wed, Nov 26, 2008 at 12:05 PM, Paul Johnson wrote: > Hi, > > I'm trying to set up some operators for applicative versions of prelude > types. For instance: > > -- | Applicative Equality. > class (Eq a) => AppEq f a where > (.==.), (./=.) :: f a -> f a -> f Bool > > instance (Applicative f, Eq a) => AppEq f a where > (.==.) = liftA2 (==) > (./=.) = liftA2 (/=) > > > Hopefully the intention is fairly straightforward: if "f" is an instance of > Applicative then the lifted implementation of the underlying type. > Otherwise I can just give my own instance, which is useful for things that > "wrap" prelude types but where "fmap" doesn't work. For instance: > > data (Ord a) => Interval a = Interval a a > > instance (Ord a) => AppEq Interval a where > i1@(Interval _ u1) .==. i2@(Interval _ u2) > | isSingleton i1 && isSingleton i2 && u1 == u2 = Interval True True > | has i1 u2 || has i2 u1 = Interval False True > | otherwise = Interval False False > i1 ./=. i2 = let Interval b1 b2 = (i1 .==. i2) in Interval (not b2) (not > b1) > > isSingleton :: (Ord a) => Interval a -> Bool > isSingleton (Interval lower upper) = lower == upper > > has :: (Ord a) => Interval a -> a -> Bool > has (Interval lower upper) v = v >= lower && v <= upper > > > You can't (easily) define fmap for Interval because the function given as an > argument might not be monotonic. So instead you have to write custom > implementations for each lifted function, as shown here for (.==.) and > (./=.) . The same principle works for AppOrd, AppNum etc, but I'm trying to > solve the problem for just AppEq for now. > > This compiles, but when I try to use it I get this in ghci: > > *Interval> let i1 = Interval 4 5 > *Interval> let i2 = Interval 4 6 > *Interval> i1 .==. i2 > > :1:0: > Overlapping instances for AppEq Interval Integer > arising from a use of `.==.' at :1:0-9 > Matching instances: > instance (Ord a) => AppEq Interval a > -- Defined at Interval.hs:(22,0)-(27,78) > instance (Control.Applicative.Applicative f, Eq a) => AppEq f a > -- Defined at AppPrelude.hs:(32,0)-(34,23) > In the expression: i1 .==. i2 > In the definition of `it': it = i1 .==. i2 > > I'm puzzled, because Interval is not an instance of Applicative, so the > second instance doesn't apply. Can anyone help me out? > > I'm using ghc 6.8.3, so its possible that this was a bug fixed in 6.10. > > Paul. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From miguelimo38 at yandex.ru Wed Nov 26 16:54:58 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Wed Nov 26 16:48:48 2008 Subject: [Haskell-cafe] Instances that shouldn't overlap In-Reply-To: <2f9b2d30811261339o515e8ac8x5a4cda25d4b8fb65@mail.gmail.com> References: <492DAC14.5030309@cogito.org.uk> <2f9b2d30811261339o515e8ac8x5a4cda25d4b8fb65@mail.gmail.com> Message-ID: Maybe it'd be more intuitive if written backwards: AppEq f a <= (Applicative f, Eq a) or even AppEq f a => (Applicative f, Eq a) On 27 Nov 2008, at 00:39, Ryan Ingram wrote: > A common mistake (and a confusing bit about typeclasses) is that > whether or not the constraints on an instance apply are irrelevant. > > Specifically, the code "instance (Applicative f, Eq a) => AppEq f a" > means that, given any types f and a, I can tell you how to make them > an instance of AppEq. But I also ask you to please add the > constraints "Applicative f" and "Eq a". That is to say, only the > stuff on the right of the => apply when determining whether an > instance applies. > > If you take out the overlapping specific instance for Interval, the > compiler will give you a different error: > > "No instance for Applicative Interval". You can see what happened > here: the compiler wants an instance for AppEq Interval Integer. It > sees the instance "AppEq f a" and adds the constraints "Ord Integer" > and "Applicative Interval". Ord Integer is already fulfilled, but it > can't discharge the constraint on Applicative, so the compile fails. > > Similarily, in your case, the compiler can't decide whether to apply > the "Ord a => AppEq Interval a" instance, or the "Applicative f, Eq a > => AppEq f a" instance; the right hand sides of the instance > declarations both match (and add different constraints to the left > hand side). > > You can use -XOverlappingInstances, but beware, dragons lie in that > direction. > > I think this is a fundamental weakness of the typeclass system, but I > haven't seen a design that avoids it for code as complicated as this. > > On Wed, Nov 26, 2008 at 12:05 PM, Paul Johnson > wrote: >> Hi, >> >> I'm trying to set up some operators for applicative versions of >> prelude >> types. For instance: >> >> -- | Applicative Equality. >> class (Eq a) => AppEq f a where >> (.==.), (./=.) :: f a -> f a -> f Bool >> >> instance (Applicative f, Eq a) => AppEq f a where >> (.==.) = liftA2 (==) >> (./=.) = liftA2 (/=) >> >> >> Hopefully the intention is fairly straightforward: if "f" is an >> instance of >> Applicative then the lifted implementation of the underlying type. >> Otherwise I can just give my own instance, which is useful for >> things that >> "wrap" prelude types but where "fmap" doesn't work. For instance: >> >> data (Ord a) => Interval a = Interval a a >> >> instance (Ord a) => AppEq Interval a where >> i1@(Interval _ u1) .==. i2@(Interval _ u2) >> | isSingleton i1 && isSingleton i2 && u1 == u2 = Interval True >> True >> | has i1 u2 || has i2 u1 = Interval False >> True >> | otherwise = Interval False >> False >> i1 ./=. i2 = let Interval b1 b2 = (i1 .==. i2) in Interval (not b2) >> (not >> b1) >> >> isSingleton :: (Ord a) => Interval a -> Bool >> isSingleton (Interval lower upper) = lower == upper >> >> has :: (Ord a) => Interval a -> a -> Bool >> has (Interval lower upper) v = v >= lower && v <= upper >> >> >> You can't (easily) define fmap for Interval because the function >> given as an >> argument might not be monotonic. So instead you have to write custom >> implementations for each lifted function, as shown here for (.==.) >> and >> (./=.) . The same principle works for AppOrd, AppNum etc, but I'm >> trying to >> solve the problem for just AppEq for now. >> >> This compiles, but when I try to use it I get this in ghci: >> >> *Interval> let i1 = Interval 4 5 >> *Interval> let i2 = Interval 4 6 >> *Interval> i1 .==. i2 >> >> :1:0: >> Overlapping instances for AppEq Interval Integer >> arising from a use of `.==.' at :1:0-9 >> Matching instances: >> instance (Ord a) => AppEq Interval a >> -- Defined at Interval.hs:(22,0)-(27,78) >> instance (Control.Applicative.Applicative f, Eq a) => AppEq f a >> -- Defined at AppPrelude.hs:(32,0)-(34,23) >> In the expression: i1 .==. i2 >> In the definition of `it': it = i1 .==. i2 >> >> I'm puzzled, because Interval is not an instance of Applicative, so >> the >> second instance doesn't apply. Can anyone help me out? >> >> I'm using ghc 6.8.3, so its possible that this was a bug fixed in >> 6.10. >> >> Paul. >> _______________________________________________ >> 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 andrewcoppin at btinternet.com Wed Nov 26 16:56:21 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Nov 26 16:50:02 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> Message-ID: <492DC605.4030602@btinternet.com> Donnie Jones wrote: > > Here is the current homepage for the LHC project: > http://lhc.seize.it/ > > Hope that helps. Yes. I found that - it just didn't *say* very much. ;-) I guess like many small projects, they're too busy *doing* it to have time to document it. From john at repetae.net Wed Nov 26 16:57:34 2008 From: john at repetae.net (John Meacham) Date: Wed Nov 26 16:51:15 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <492DBFC7.20602@pikewerks.com> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DBFC7.20602@pikewerks.com> Message-ID: <20081126215734.GD9558@sliver.repetae.net> On Wed, Nov 26, 2008 at 03:29:43PM -0600, Jake McArthur wrote: >> Interesting. I can't find out any information about this... > > It is a fork of the JHC compiler, which should be easier to look up. > There is also Hugs, as you mentioned. In addition, you may want to look > at YHC and NHC. Hmm.. This one is news to me. John -- John Meacham - ?repetae.net?john? From andrewcoppin at btinternet.com Wed Nov 26 16:59:56 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Nov 26 16:53:40 2008 Subject: [Haskell-cafe] Finalisers Message-ID: <492DC6DC.7080105@btinternet.com> Here's an interesting question... Is it possible to attach finalisers to a value? (That is, have some Haskell code executed when the item in question is reclaimed by the GC.) I'm interested in knowing whether a particular data structure is shared (i.e., whether it's safe to mutate it or whether it must be copied first), and a simple reference-counting scheme looks like the easiest option. From kili at outback.escape.de Wed Nov 26 16:58:34 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Wed Nov 26 16:53:54 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <492DC105.5010803@btinternet.com> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DBFC7.20602@pikewerks.com> <492DC105.5010803@btinternet.com> Message-ID: <20081126215834.GA12265@petunia.outback.escape.de> On Wed, Nov 26, 2008 at 09:35:01PM +0000, Andrew Coppin wrote: > >It is a fork of the JHC compiler, which should be easier to look up. > >There is also Hugs, as you mentioned. In addition, you may want to > >look at YHC and NHC. > > Yeah, the "implementations" page on the Wiki basically says that there's > GHC and Hugs, and there's also these things called YHC, NHC and JHC. All > the documentation I've read makes these latter compilers sound highly > experimental and unusable. I would't call nhc experimental; it's quite usable, at least for standard Haskell-98 stuff (plus some language extensions). Ciao, Kili From jgmorris at cecs.pdx.edu Wed Nov 26 17:05:49 2008 From: jgmorris at cecs.pdx.edu (J. Garrett Morris) Date: Wed Nov 26 16:59:31 2008 Subject: [Haskell-cafe] Instances that shouldn't overlap In-Reply-To: References: <492DAC14.5030309@cogito.org.uk> <2f9b2d30811261339o515e8ac8x5a4cda25d4b8fb65@mail.gmail.com> Message-ID: <6cf91caa0811261405x7154e0c6le41f5fda7e3f5768@mail.gmail.com> On Wed, Nov 26, 2008 at 1:54 PM, Miguel Mitrofanov wrote: > Maybe it'd be more intuitive if written backwards: > > AppEq f a <= (Applicative f, Eq a) > > or even > > AppEq f a => (Applicative f, Eq a) The first is good, the second isn't. The first says the right thing: if you can prove Applicative f and Eq a, you have a way to prove AppEq f a. The second has the implication the wrong way around. Classes get the implication wrong too: class Eq a => Ord a doesn't say that if you can prove Eq a you can prove Ord a; it says that if you can prove Ord a you can prove Eq a /g -- I am in here From dons at galois.com Wed Nov 26 17:10:45 2008 From: dons at galois.com (Don Stewart) Date: Wed Nov 26 17:04:27 2008 Subject: [Haskell-cafe] Finalisers In-Reply-To: <492DC6DC.7080105@btinternet.com> References: <492DC6DC.7080105@btinternet.com> Message-ID: <20081126221045.GB19571@scytale.galois.com> andrewcoppin: > Here's an interesting question... Is it possible to attach finalisers to > a value? (That is, have some Haskell code executed when the item in > question is reclaimed by the GC.) I'm interested in knowing whether a > particular data structure is shared (i.e., whether it's safe to mutate > it or whether it must be copied first), and a simple reference-counting > scheme looks like the easiest option. Yes. From dave at zednenem.com Wed Nov 26 17:14:57 2008 From: dave at zednenem.com (David Menendez) Date: Wed Nov 26 17:08:39 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <20081126215834.GA12265@petunia.outback.escape.de> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DBFC7.20602@pikewerks.com> <492DC105.5010803@btinternet.com> <20081126215834.GA12265@petunia.outback.escape.de> Message-ID: <49a77b7a0811261414n2365c981k13e6a1ea007dd3c1@mail.gmail.com> On Wed, Nov 26, 2008 at 4:58 PM, Matthias Kilian wrote: > On Wed, Nov 26, 2008 at 09:35:01PM +0000, Andrew Coppin wrote: >> >It is a fork of the JHC compiler, which should be easier to look up. >> >There is also Hugs, as you mentioned. In addition, you may want to >> >look at YHC and NHC. >> >> Yeah, the "implementations" page on the Wiki basically says that there's >> GHC and Hugs, and there's also these things called YHC, NHC and JHC. All >> the documentation I've read makes these latter compilers sound highly >> experimental and unusable. > > I would't call nhc experimental; it's quite usable, at least for > standard Haskell-98 stuff (plus some language extensions). How old is nhc? I've always thought of it as one of the "big three", but I don't really know how far back it goes compared to ghc. -- Dave Menendez From duncan.coutts at worc.ox.ac.uk Wed Nov 26 17:17:05 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Nov 26 17:10:55 2008 Subject: [Haskell-cafe] Re: [Haskell] Wait for *either* MVar to be set In-Reply-To: <2f9b2d30811261325q4c2d1949v1d8870ec9a192629@mail.gmail.com> References: <492DA65B.10305@charter.net> <2f9b2d30811261325q4c2d1949v1d8870ec9a192629@mail.gmail.com> Message-ID: <1227737825.19577.31.camel@localhost> On Wed, 2008-11-26 at 13:25 -0800, Ryan Ingram wrote: > In fact: > > > import Control.Concurrent.STM > > import Control.Concurrent.STM.TMVar > > > -- gets a value from one of a list of TMVars > > takeTMVars :: [TMVar a] -> STM (TMVar a, a) > > takeTMVars = foldr fetch retry where > > fetch v act = (takeTMVar v >>= \a -> return (v, a)) `orElse` act > > > -- puts the given value into exactly one of a list of TMVars > > putTMVars :: [TMVar a] -> a -> STM (TMVar a) > > putTMVars vs a = foldr put retry vs where > > put v act = (putTMVar v a >> return v) `orElse` act Of course those are TMVars, using STM. So in STM it is easy, whereas with MVars it is a bit harder. Duncan From duncan.coutts at worc.ox.ac.uk Wed Nov 26 17:28:21 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Nov 26 17:22:21 2008 Subject: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs In-Reply-To: <20081126143832.GC15463@brighton.ac.uk> References: <20081126143832.GC15463@brighton.ac.uk> Message-ID: <1227738501.19577.42.camel@localhost> On Wed, 2008-11-26 at 14:38 +0000, Eric Kow wrote: > Hi everybody, > > This advisory is for people who have installed darcs 2.1.2 via the > Cabal build method. As you may have noticed, the cabalised darcs > sometimes fails with errors like > > Codec.Compression.Zlib: incorrect data check > > Why this happens > ---------------- > Older versions of darcs can to produce gzipped files with broken CRCs. > We never noticed this because our homegrown wrapper around the C libz > library does not pick up these errors. I should note that one moral of this story is to check that your FFI imports are correct. That is, check they import the foreign functions at the right Haskell types. In this case the mistake was that the foreign function returned a C int, but the Haskell foreign import declaration stated that the C function returned IO () rather than IO CInt. This is where a tool really helps. The hsc2hs tool cannot check the cross-language type consistency while c2hs can. It reads the C header files and generates the FFI imports at the correct Haskell types. The downside is that c2hs is not shipped with ghc, it is a bit slower and it's not quite so good with structures. I think there is a need for a tool like c2hs but that works in a checking mode rather than in a generating mode. It would use much of the same code as c2hs but it would read the C header files and the .hs file (via ghc api) and check that the FFI imports are using the right types. That way it could be run to check a package without the checker tool being needed at build time on every platform. The downside would be that some C header files differ between platforms and c2hs handles this fine while a checker tool might say it's ok on one platform and that may not carry over to another. Still, it would be an improvement on just using raw FFI imports (or hsc2hs, which is really the same thing). Duncan From dons at galois.com Wed Nov 26 17:30:45 2008 From: dons at galois.com (Don Stewart) Date: Wed Nov 26 17:24:24 2008 Subject: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs In-Reply-To: <1227738501.19577.42.camel@localhost> References: <20081126143832.GC15463@brighton.ac.uk> <1227738501.19577.42.camel@localhost> Message-ID: <20081126223045.GF19571@scytale.galois.com> duncan.coutts: > On Wed, 2008-11-26 at 14:38 +0000, Eric Kow wrote: > > Hi everybody, > > > > This advisory is for people who have installed darcs 2.1.2 via the > > Cabal build method. As you may have noticed, the cabalised darcs > > sometimes fails with errors like > > > > Codec.Compression.Zlib: incorrect data check > > > > Why this happens > > ---------------- > > Older versions of darcs can to produce gzipped files with broken CRCs. > > We never noticed this because our homegrown wrapper around the C libz > > library does not pick up these errors. > > I should note that one moral of this story is to check that your FFI > imports are correct. That is, check they import the foreign functions at > the right Haskell types. In this case the mistake was that the foreign > function returned a C int, but the Haskell foreign import declaration > stated that the C function returned IO () rather than IO CInt. > > This is where a tool really helps. The hsc2hs tool cannot check the > cross-language type consistency while c2hs can. It reads the C header > files and generates the FFI imports at the correct Haskell types. > > The downside is that c2hs is not shipped with ghc, it is a bit slower > and it's not quite so good with structures. > > I think there is a need for a tool like c2hs but that works in a > checking mode rather than in a generating mode. It would use much of the > same code as c2hs but it would read the C header files and the .hs file > (via ghc api) and check that the FFI imports are using the right types. > That way it could be run to check a package without the checker tool > being needed at build time on every platform. The downside would be that > some C header files differ between platforms and c2hs handles this fine > while a checker tool might say it's ok on one platform and that may not > carry over to another. Still, it would be an improvement on just using > raw FFI imports (or hsc2hs, which is really the same thing). Yes, this plagued xmonad's X11 bindings: almost all bugs in the last 12 months were due to FFI bindings. I'd love a hsc2hs -Wall mode. -- Don From josef.svenningsson at gmail.com Wed Nov 26 17:33:02 2008 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Wed Nov 26 17:26:45 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <49a77b7a0811261414n2365c981k13e6a1ea007dd3c1@mail.gmail.com> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DBFC7.20602@pikewerks.com> <492DC105.5010803@btinternet.com> <20081126215834.GA12265@petunia.outback.escape.de> <49a77b7a0811261414n2365c981k13e6a1ea007dd3c1@mail.gmail.com> Message-ID: <8dde104f0811261433o61fe5c9ao1f57046b0e5192e1@mail.gmail.com> On Wed, Nov 26, 2008 at 11:14 PM, David Menendez wrote: > How old is nhc? I've always thought of it as one of the "big three", > but I don't really know how far back it goes compared to ghc. > The following page suggests that it was released mid 1994 but there could of course have been earlier releases. http://www.cs.chalmers.se/pub/haskell/nhc/old/ Perhaps Malcolm Wallace knows more. Cheers, Josef From bulat.ziganshin at gmail.com Wed Nov 26 17:32:45 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Nov 26 17:26:59 2008 Subject: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs In-Reply-To: <1227738501.19577.42.camel@localhost> References: <20081126143832.GC15463@brighton.ac.uk> <1227738501.19577.42.camel@localhost> Message-ID: <1478119594.20081127013245@gmail.com> Hello Duncan, Thursday, November 27, 2008, 1:28:21 AM, you wrote: > checking mode rather than in a generating mode. It would use much of the > same code as c2hs but it would read the C header files and the .hs file > (via ghc api) and check that the FFI imports are using the right types. there is FFI imports generator (HSFFIG?), written by Dmitry Golubovsky -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Wed Nov 26 17:44:00 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Nov 26 17:37:45 2008 Subject: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs In-Reply-To: <20081126223045.GF19571@scytale.galois.com> References: <20081126143832.GC15463@brighton.ac.uk> <1227738501.19577.42.camel@localhost> <20081126223045.GF19571@scytale.galois.com> Message-ID: <1227739440.19577.45.camel@localhost> On Wed, 2008-11-26 at 14:30 -0800, Don Stewart wrote: > > I think there is a need for a tool like c2hs but that works in a > > checking mode rather than in a generating mode. It would use much of the > > same code as c2hs but it would read the C header files and the .hs file > > (via ghc api) and check that the FFI imports are using the right types. > > That way it could be run to check a package without the checker tool > > being needed at build time on every platform. The downside would be that > > some C header files differ between platforms and c2hs handles this fine > > while a checker tool might say it's ok on one platform and that may not > > carry over to another. Still, it would be an improvement on just using > > raw FFI imports (or hsc2hs, which is really the same thing). > > Yes, this plagued xmonad's X11 bindings: almost all bugs in the last 12 > months were due to FFI bindings. > > I'd love a hsc2hs -Wall mode. Right, but it cannot be hsc2hs. The model of hsc2hs simply does cannot support such a thing because it does not actually know the C types of anything. It would have to be more on the model of c2hs, using Language.C to work out the C types and then map them to Haskell ones, to check they're the same as the declared types in the .hs files. Duncan From malcolm.wallace at cs.york.ac.uk Wed Nov 26 18:16:31 2008 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Nov 26 18:13:06 2008 Subject: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs In-Reply-To: <1227739440.19577.45.camel@localhost> References: <20081126143832.GC15463@brighton.ac.uk> <1227738501.19577.42.camel@localhost> <20081126223045.GF19571@scytale.galois.com> <1227739440.19577.45.camel@localhost> Message-ID: <4E0EC0E7-8409-4E0C-8D83-B14964A0A14D@cs.york.ac.uk> > ... to work out the C types and then map them to Haskell ones, to > check they're the same as the declared types in the .hs files. I'd like to point out that the FFI specification already has such a mechanism. That is, if you use the optional specification of a header file for each foreign import, and if your Haskell compiler can compile via C, then any checking that types match between Haskell and C can be performed automatically, by the backend C compiler. [ OK, so that is not the whole story, and there are good reasons why it might not always work out, but I still think it was an important principle in the original FFI design. ] Regards, Malcolm From jwlato at gmail.com Wed Nov 26 18:25:28 2008 From: jwlato at gmail.com (John Lato) Date: Wed Nov 26 18:19:11 2008 Subject: [Haskell-cafe] build tools and Cabal In-Reply-To: <1227644315.19577.21.camel@localhost> References: <9979e72e0811241730n46ee2c06p1093f654f6896bee@mail.gmail.com> <1227644315.19577.21.camel@localhost> Message-ID: <9979e72e0811261525n4e03b7d1t6e8d0a647bc6a20e@mail.gmail.com> On Tue, Nov 25, 2008 at 8:18 PM, Duncan Coutts wrote: > On Tue, 2008-11-25 at 01:30 +0000, John Lato wrote: >> Hello, >> >> Cabal allows specifying arguments for tools it recognizes on the >> command line, e.g. >> >> runhaskell Setup.hs configure --c2hs-option=some_option >> >> Unfortunately, I can't find a way to make this work with .cabal (or >> .buildinfo) files, except for the specific cases of ghc, hugs, and >> nhc98 options. Am I missing something? > > No. > >> If not, could this be added easily? > > Yes, but it's not clear that we should. > >> It would be very helpful as I'm trying to work around the broken cpp >> Apple provides. > > Perhaps we should do the workaround once rather than adding the > workaround to every package. > > What is the problem exactly? > This is with c2hs on a Mac. Using $ cpp --version i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367) Copyright (C) 2005 Free Software Foundation, Inc. $ c2hs -d trace --cppopts=-I/Library/Frameworks/CsoundLib.framework/Headers Interface.chs Attempting to read file `Interface.chs'... ...parsing `Interface'... ...successfully loaded `Interface'. Invoking cpp as `cpp -x=c -I/Library/Frameworks/CsoundLib.framework/Headers Interface.chs.h >Interface.i'... Attempting to read file `Interface.i'... ...parsing `Interface.i'... c2hs: Error in C header file. /usr/include/sys/resource.h:167: (column 1) [FATAL] >>> Syntax error! The symbol `/' does not fit here. This error appears in other files too, at least /usr/include/sys/signal.h. There are also some errors caused by the csound.h file, but I can probably get the csound maintainers to change that. The problem with csound.h is that it has a few #defines preceded by whitespace, which Apple's cpp chooses to leave in the output rather than process. The problem with signal.h and resource.h is that they have //comments, which cpp again chooses to retain, causing the error when Interface.i is being parsed. Oddly, cpp leaves the //comments in place even when called with -x=c++. My workaround is to configure with --c2hs-option=--cpp=gcc --c2hs-option=--cppopt=-E --c2hs-option=--cppopt=-xc. This has the desired behavior, but it's a lot for a user to type in. I could make a script to call configure with the correct options, but that sort of system-dependent configuration seems like exactly the sort of thing that cabal and configure are supposed to be able to work out. So that's the problem. I don't know if this should be addressed as a cabal issue or a c2hs issue. I would say that it's Apple's problem, but that won't help moving to a solution. I'm not even sure that Apple's software is doing anything technical incorrect. Regards, John From dagit at codersbase.com Wed Nov 26 18:32:18 2008 From: dagit at codersbase.com (Jason Dagit) Date: Wed Nov 26 18:25:59 2008 Subject: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs In-Reply-To: <4E0EC0E7-8409-4E0C-8D83-B14964A0A14D@cs.york.ac.uk> References: <20081126143832.GC15463@brighton.ac.uk> <1227738501.19577.42.camel@localhost> <20081126223045.GF19571@scytale.galois.com> <1227739440.19577.45.camel@localhost> <4E0EC0E7-8409-4E0C-8D83-B14964A0A14D@cs.york.ac.uk> Message-ID: On Wed, Nov 26, 2008 at 3:16 PM, Malcolm Wallace < malcolm.wallace@cs.york.ac.uk> wrote: > ... to work out the C types and then map them to Haskell ones, to >> check they're the same as the declared types in the .hs files. >> > > I'd like to point out that the FFI specification already has such a > mechanism. > That is, if you use the optional specification of a header file for each > foreign import, and if your Haskell compiler can compile via C, then any > checking that types match between Haskell and C can be performed > automatically, by the backend C compiler. > > [ OK, so that is not the whole story, and there are good reasons why it > might not always work out, but I still think it was an important principle > in the original FFI design. ] Would this method work with return types since C compilers tend to let you ignore those? In this example that brought up this discussion it was in fact an ignored return value that caused the problem. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081126/6a755328/attachment.htm From nominolo at googlemail.com Wed Nov 26 19:07:26 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Wed Nov 26 19:01:09 2008 Subject: [Haskell-cafe] Finalisers In-Reply-To: <492DC6DC.7080105@btinternet.com> References: <492DC6DC.7080105@btinternet.com> Message-ID: <916b84820811261607r4684c1feo3368477f78d8f2c8@mail.gmail.com> Possible, yes. Advisable, no. There is no guarantee that the finaliser is ever run, they are expensive (since they need to be kept separately and checked after each GC) and there are easier methods. Lava [1] uses a very lightweight sharing detection mechanism. Depending on your problem you might also want to look at Oleg's approach to explicit sharing in a DSL [2]. [1]: http://www.cs.chalmers.se/~koen/Lava/papers.html [2]: http://www.mail-archive.com/haskell-cafe@haskell.org/msg37765.html 2008/11/26 Andrew Coppin : > Here's an interesting question... Is it possible to attach finalisers to a > value? (That is, have some Haskell code executed when the item in question > is reclaimed by the GC.) I'm interested in knowing whether a particular data > structure is shared (i.e., whether it's safe to mutate it or whether it must > be copied first), and a simple reference-counting scheme looks like the > easiest option. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Push the envelope. Watch it bend. From bjpop at csse.unimelb.edu.au Wed Nov 26 19:49:07 2008 From: bjpop at csse.unimelb.edu.au (Bernie Pope) Date: Wed Nov 26 19:43:09 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <492DC105.5010803@btinternet.com> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DBFC7.20602@pikewerks.com> <492DC105.5010803@btinternet.com> Message-ID: On 27/11/2008, at 8:35 AM, Andrew Coppin wrote: > Jake McArthur wrote: >> Andrew Coppin wrote: >>> Don Stewart wrote: >>>> Noteworthy, >>>> * lhc-20081121: ?Lhc Haskell Compiler? >>>> >>> >>> Interesting. I can't find out any information about this... >> >> It is a fork of the JHC compiler, which should be easier to look >> up. There is also Hugs, as you mentioned. In addition, you may want >> to look at YHC and NHC. > > Yeah, the "implementations" page on the Wiki basically says that > there's GHC and Hugs, and there's also these things called YHC, NHC > and JHC. All the documentation I've read makes these latter > compilers sound highly experimental and unusable. (I don't recall > specifically which of them, but I remember hearing it can't even > compile the Prelude yet.) They seem like small projects which are > probably interesting to hack with, but not much use if you're trying > to produce production-grade compiled code to give to a customer... > > OTOH, I haven't ever attempted to *use* any of these compilers. I > only read about them... Don't forget hbc. There's plenty of information about all the compilers in the history of haskell paper, including a timeline: http://research.microsoft.com/users/simonpj/papers/history-of-haskell/index.htm Cheers, Bernie. From ok at cs.otago.ac.nz Wed Nov 26 21:19:53 2008 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Wed Nov 26 21:13:41 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <492DC605.4030602@btinternet.com> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DC605.4030602@btinternet.com> Message-ID: <62A837ED-079C-4E15-8863-75AFCDA4BF28@cs.otago.ac.nz> On 27 Nov 2008, at 10:56 am, Andrew Coppin wrote: > Donnie Jones wrote: >> Here is the current homepage for the LHC project: >> http://lhc.seize.it/ >> Yes. I found that - it just didn't *say* very much. ;-) I really really wish there were just one more sentence on that page saying WHY there is a fork of JHC. From dagit at codersbase.com Wed Nov 26 22:20:12 2008 From: dagit at codersbase.com (Jason Dagit) Date: Wed Nov 26 22:13:55 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <62A837ED-079C-4E15-8863-75AFCDA4BF28@cs.otago.ac.nz> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DC605.4030602@btinternet.com> <62A837ED-079C-4E15-8863-75AFCDA4BF28@cs.otago.ac.nz> Message-ID: On Wed, Nov 26, 2008 at 6:19 PM, Richard O'Keefe wrote: > > On 27 Nov 2008, at 10:56 am, Andrew Coppin wrote: > >> Donnie Jones wrote: >> >>> Here is the current homepage for the LHC project: >>> http://lhc.seize.it/ >>> Yes. I found that - it just didn't *say* very much. ;-) >>> >> > I really really wish there were just one more sentence on > that page saying WHY there is a fork of JHC. > I spoke with the author of the fork a bit in IRC around the time it happened and my understanding is that: 1) John sternly objects to using cabal as the build system for JHC 2) JHC was seeing very little development activity by John 3) The author of the fork has philosophically different ideas about project management I really hope JHC and LHC can continue to share code and are able to be collaborating projects instead of competing ones. We can see that LHC already has an increase in activity and the new team that is forming is very interested in clean up and factorization. That is, I've seen some good discussions about using libraries instead of project specific functionality between LHC contributors. I hope John doesn't take the fork as any sort of aggressive or insulting action. He's made a compiler that is sufficiently interesting to have users that want to take over. I'm not involved in either fork in either way, but it's quite interesting to watch and I can see parallels to a different Haskell project. Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081126/c71f8096/attachment.htm From vigalchin at gmail.com Thu Nov 27 00:48:19 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Nov 27 00:42:01 2008 Subject: [Haskell-cafe] Philip Wadler video on Howard-Curry Correspondence ??? Message-ID: <5ae4f2ba0811262148y1054a725wbf217dbbfc6334f3@mail.gmail.com> Hello, I am reading re-reading Prof. Wadler paper Proofs are Programs: 19th Century Logic and 21st Century Computing but also want to re-read watch his video on same subject..... ??? Very kind thanks, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081126/f90d0bcb/attachment-0001.htm From rl at cse.unsw.edu.au Thu Nov 27 02:45:42 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Thu Nov 27 02:39:34 2008 Subject: [Haskell-cafe] Need machine for DPH benchmarking Message-ID: <37006B2E-B4CF-46F9-9420-61A556B3DF4A@cse.unsw.edu.au> Hi all, we, the DPH team, are at the moment in the very unfortunate situation of not having a proper machine for running our benchmarks on. Could a kind soul maybe give us (i.e., me) access to a quadcore or 2xquadcore x86 Linux or OS X machine? I only need to build ghc on it and run small benchmarks which never take more than a couple of minutes, maybe once every couple of days or so. We do need to use all cores, though, so no other CPU-intensive processes can be running during benchmarking. This is only for a week or two, until we get our own machine. We would be eternally grateful and won't forget you when DPH takes over the world. Roman From oleg at okmij.org Thu Nov 27 02:51:50 2008 From: oleg at okmij.org (oleg@okmij.org) Date: Thu Nov 27 02:45:48 2008 Subject: [Haskell-cafe] Instances that shouldn't overlap Message-ID: <20081127075150.691FEAB0F@Adric.metnet.fnmoc.navy.mil> Paul Johnson wrote: > class (Eq a) => AppEq f a where > instance (Applicative f, Eq a) => AppEq f a where > instance (Ord a) => AppEq Interval a where In Haskell, instances are selected based solely on the types in the head. Constraints like `Applicative f' are not consulted when the instance is being selected. Rather, constraints are checked after the instance has been selected. The above two instances are overlapping since Interval is a particular case of `f'. That said, it is possible to select an instance based on constraints. The approach is described at http://haskell.org/haskellwiki/GHC/AdvancedOverlap From allbery at ece.cmu.edu Thu Nov 27 03:22:00 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Nov 27 03:15:54 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <20081126215834.GA12265@petunia.outback.escape.de> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DBFC7.20602@pikewerks.com> <492DC105.5010803@btinternet.com> <20081126215834.GA12265@petunia.outback.escape.de> Message-ID: <42EE2A3F-C3C1-4D08-A024-8214A66B0F1A@ece.cmu.edu> On 2008 Nov 26, at 16:58, Matthias Kilian wrote: > On Wed, Nov 26, 2008 at 09:35:01PM +0000, Andrew Coppin wrote: >>> It is a fork of the JHC compiler, which should be easier to look up. >>> There is also Hugs, as you mentioned. In addition, you may want to >>> look at YHC and NHC. >> >> Yeah, the "implementations" page on the Wiki basically says that >> there's >> GHC and Hugs, and there's also these things called YHC, NHC and >> JHC. All >> the documentation I've read makes these latter compilers sound highly >> experimental and unusable. > > I would't call nhc experimental; it's quite usable, at least for > standard Haskell-98 stuff (plus some language extensions). On a related topic: whatever happened to the compiler shootout? (Aside from dons leaving unsw) -- 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 Thu Nov 27 03:23:46 2008 From: dons at galois.com (Don Stewart) Date: Thu Nov 27 03:17:28 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <42EE2A3F-C3C1-4D08-A024-8214A66B0F1A@ece.cmu.edu> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DBFC7.20602@pikewerks.com> <492DC105.5010803@btinternet.com> <20081126215834.GA12265@petunia.outback.escape.de> <42EE2A3F-C3C1-4D08-A024-8214A66B0F1A@ece.cmu.edu> Message-ID: <20081127082346.GC20722@scytale.galois.com> allbery: > On 2008 Nov 26, at 16:58, Matthias Kilian wrote: > >On Wed, Nov 26, 2008 at 09:35:01PM +0000, Andrew Coppin wrote: > >>>It is a fork of the JHC compiler, which should be easier to look up. > >>>There is also Hugs, as you mentioned. In addition, you may want to > >>>look at YHC and NHC. > >> > >>Yeah, the "implementations" page on the Wiki basically says that > >>there's > >>GHC and Hugs, and there's also these things called YHC, NHC and > >>JHC. All > >>the documentation I've read makes these latter compilers sound highly > >>experimental and unusable. > > > >I would't call nhc experimental; it's quite usable, at least for > >standard Haskell-98 stuff (plus some language extensions). > > > On a related topic: whatever happened to the compiler shootout? > (Aside from dons leaving unsw) Malcolm continues the tradition, http://code.haskell.org/nobench/ From ketil at malde.org Thu Nov 27 03:44:03 2008 From: ketil at malde.org (Ketil Malde) Date: Thu Nov 27 03:37:45 2008 Subject: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs In-Reply-To: (Jason Dagit's message of "Wed\, 26 Nov 2008 15\:32\:18 -0800") References: <20081126143832.GC15463@brighton.ac.uk> <1227738501.19577.42.camel@localhost> <20081126223045.GF19571@scytale.galois.com> <1227739440.19577.45.camel@localhost> <4E0EC0E7-8409-4E0C-8D83-B14964A0A14D@cs.york.ac.uk> Message-ID: <87prkhsgmk.fsf@malde.org> "Jason Dagit" writes: > That is, if you use the optional specification of a header file for each > foreign import, and if your Haskell compiler can compile via C, then any > checking that types match between Haskell and C can be performed > automatically, by the backend C compiler. > Would this method work with return types since C compilers tend to let you > ignore those? In this example that brought up this discussion it was in fact > an ignored return value that caused the problem. I've tried to look at GCC's warning options, but couldn't make it emit a warning on an ignored result. (Doesn't mean it isn't in there, of course) -k -- If I haven't seen further, it is by standing in the footprints of giants From ketil at malde.org Thu Nov 27 03:51:12 2008 From: ketil at malde.org (Ketil Malde) Date: Thu Nov 27 03:44:54 2008 Subject: [Haskell-cafe] Windows vs. Linux x64 In-Reply-To: <200811262120.31017.bartek@sudety.it> ("Bartosz =?utf-8?Q?W?= =?utf-8?Q?=C3=B3jcik=22's?= message of "Wed\, 26 Nov 2008 21\:20\:30 +0100") References: <200811250056.27632.bartek@sudety.it> <87myfnv8u0.fsf@malde.org> <20081126011626.GC9558@sliver.repetae.net> <200811262120.31017.bartek@sudety.it> Message-ID: <87ljv5sgan.fsf@malde.org> Bartosz W?jcik writes: > Win32 Core2Duo 1.8GHz 1GB RAM > 17 Mb total memory in use > MUT time 56.97s ( 57.02s elapsed) > %GC time 0.5% > Win32 Core2Duo 2.2GHz 2GB RAM > 17 Mb total memory in use > MUT time 57.44s ( 57.53s elapsed) > %GC time 0.7% (0.8% elapsed) So, despite the CPU being 25% faster, it's exactly as fast. Memory bound? > Win32 P4 2.8GHz 1GB RAM > 17 Mb total memory in use > MUT time 171.64s (175.78s elapsed) > %GC time 1.7% (1.5% elapsed) You're doing divisions, and I seem to remember division being an operation that wreaked havoc with the P4's ALU or trace cache, or something like that. > Linux64 Core2Duo 2.2GHz 2GB RAM > 41 MB total memory in use (1 MB lost due to fragmentation) > MUT time 68.26s ( 68.92s elapsed) > %GC time 0.9% (1.1% elapsed) > Linux32 Core2Duo 2.3GHz 4GB RAM > 17 Mb total memory in use > ? MUT ? time ? 51.77s ?( 51.83s elapsed) > ? %GC time ? ? ? 0.5% ?(0.6% elapsed) Interesting that Linux32 is actually faster than Win32. Different cache sizes? -k -- If I haven't seen further, it is by standing in the footprints of giants From dominic.steinitz at blueyonder.co.uk Thu Nov 27 04:15:47 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Thu Nov 27 04:21:12 2008 Subject: [Haskell-cafe] Need machine for DPH benchmarking Message-ID: <492E6543.4060401@blueyonder.co.uk> > we, the DPH team, are at the moment in the very unfortunate situation > of not having a proper machine for running our benchmarks on. Could a > kind soul maybe give us (i.e., me) access to a quadcore or 2xquadcore > x86 Linux or OS X machine? I only need to build ghc on it and run > small benchmarks which never take more than a couple of minutes, maybe > once every couple of days or so. We do need to use all cores, though, > so no other CPU-intensive processes can be running during > benchmarking. This is only for a week or two, until we get our own > machine. We would be eternally grateful and won't forget you when DPH > takes over the world. > > Roman > Roman, Graeme can set you up on an 8 core machine if you email him. Dominic. From duncan.coutts at worc.ox.ac.uk Thu Nov 27 04:28:24 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 27 04:22:18 2008 Subject: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs In-Reply-To: <4E0EC0E7-8409-4E0C-8D83-B14964A0A14D@cs.york.ac.uk> References: <20081126143832.GC15463@brighton.ac.uk> <1227738501.19577.42.camel@localhost> <20081126223045.GF19571@scytale.galois.com> <1227739440.19577.45.camel@localhost> <4E0EC0E7-8409-4E0C-8D83-B14964A0A14D@cs.york.ac.uk> Message-ID: <1227778104.19577.49.camel@localhost> On Wed, 2008-11-26 at 23:16 +0000, Malcolm Wallace wrote: > > ... to work out the C types and then map them to Haskell ones, to > > check they're the same as the declared types in the .hs files. > > I'd like to point out that the FFI specification already has such a > mechanism. > That is, if you use the optional specification of a header file for > each foreign import, and if your Haskell compiler can compile via C, > then any checking that types match between Haskell and C can be > performed automatically, by the backend C compiler. Yes, it would have caught a similar problem in an argument position, but not in the result. > [ OK, so that is not the whole story, and there are good reasons why > it might not always work out, but I still think it was an important > principle in the original FFI design. ] And covering those holes requires a tool that can grok C. Duncan From simonpj at microsoft.com Thu Nov 27 04:29:19 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Nov 27 04:23:19 2008 Subject: [Haskell-cafe] Fun with type functions Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33281447D7F@EA-EXMSG-C334.europe.corp.microsoft.com> Friends GHC has embodied data type families since 6.8, and now type synonym families (aka type functions) in 6.10. However, apart from our initial papers there isn't much published material about how to *use* type families. But that hasn't stopped you: quite a few people are using them already, and of course there is a rich seam of work on using functional dependencies to express type-level computation. Ken Shan and Oleg Kiselyov and I are collaborating to write a paper for an upcoming workshop, under the general rubric of "Fun with type functions" (in homage to Thomas Hallgren's paper "Fun with functional dependencies" and Ralf Hinze's paper "Fun with phantom types"). So this message is to ask you: can you tell us about the most persuasive, fun application you've encountered, for type families or functional dependencies? Simple is good. It doesn't have to be elaborate: just something that does something useful you could not have done otherwise. Pointers to email threads are fine. Don't assume we already know about them (even if we participated in the thread :-) Part of what we're interested in is that *you* found the example compelling. Many thanks Simon, Ken, Oleg PS: I'm broadcasting this message to GHC-users and Haskell-cafe, but to avoid deluging ghc-users, please reply just to us and Haskell cafe. (Interested ghc-users can follow the threads there from the archives if they want.) From magnus at therning.org Thu Nov 27 05:36:17 2008 From: magnus at therning.org (Magnus Therning) Date: Thu Nov 27 05:29:59 2008 Subject: [Haskell-cafe] Fun with type functions In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33281447D7F@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33281447D7F@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On Thu, Nov 27, 2008 at 9:29 AM, Simon Peyton-Jones wrote: > Friends > > GHC has embodied data type families since 6.8, and now type synonym families (aka type functions) in 6.10. However, apart from our initial papers there isn't much published material about how to *use* type families. But that hasn't stopped you: quite a few people are using them already, and of course there is a rich seam of work on using functional dependencies to express type-level computation. > > Ken Shan and Oleg Kiselyov and I are collaborating to write a paper for an upcoming workshop, under the general rubric of "Fun with type functions" (in homage to Thomas Hallgren's paper "Fun with functional dependencies" and Ralf Hinze's paper "Fun with phantom types"). > > So this message is to ask you: > > can you tell us about the most persuasive, fun application > you've encountered, for type families or functional dependencies? > > Simple is good. It doesn't have to be elaborate: just something that does something useful you could not have done otherwise. Pointers to email threads are fine. Don't assume we already know about them (even if we participated in the thread :-) Part of what we're interested in is that *you* found the example compelling. > > Many thanks I documented, [1] and [2], my first encounter with functional dependencies. Maybe not a persuasive example, but I felt it was a fairly good introduction to them. /M [1]: http://therning.org/magnus/archives/354 [2]: http://therning.org/magnus/archives/355 -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?org http://therning.org/magnus identi.ca|twitter: magthe From kowey at darcs.net Thu Nov 27 05:49:58 2008 From: kowey at darcs.net (Eric Kow) Date: Thu Nov 27 05:43:40 2008 Subject: [Haskell-cafe] Re: [darcs-users] workarounds for Codec.Compression.Zlib errors in darcs In-Reply-To: <20081126143832.GC15463@brighton.ac.uk> References: <20081126143832.GC15463@brighton.ac.uk> Message-ID: <20081127104956.GG17011@brighton.ac.uk> On Wed, Nov 26, 2008 at 14:38:33 +0000, Eric Kow wrote: > In principle, the same advice applies for Windows users, with more > details hopefully to follow on how the C libz in a GHC-accesible > location. Details to follow. As promised, here are the details for installing darcs using our old internal binding to libz on Windows. Again, the instructions are either to cabal configure -f -external-zlib (Or to wait for darcs 2.1.2.3 to appear on hackage) Thanks to Salvatore Insalaco, our Windows Czar! ---------------------------------------------------------------------- There're two zlib versions for Windows: one compiled with ccall convention, and one with stdcall convention. We need the ccall one, at the address: http://gnuwin32.sourceforge.net/packages/zlib.htm The other one will *appear* to work, but darcs will segfault as soon as the first call to zlib is made. This is the step-by-step howto: 1) Download the binary from http://gnuwin32.sourceforge.net/downlinks/zlib-bin-zip.php and unzip it. 2) Copy the zlib1.dll file in bin directory in ghc's gcc-lib directory, and then rename it libz.dll. 3a) Copy the zlib1.dll file in c:\windows directory, WITHOUT renaming it. OR 3b) If you don't want to pollute your windows directory, just copy it in whatever directory is in the search PATH, or in the one you'll place darcs.exe binary. That's all. The cabal install will then just work. By the way: that's similar to the how-to for making curl work. Maybe we can update the windows building instructions providing a "pre-install" instructions to make cabal install darcs just work. -- Eric Kow PGP Key ID: 08AC04F9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081127/0137e1bc/attachment.bin From DekuDekuplex at Yahoo.com Thu Nov 27 06:33:37 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Thu Nov 27 06:27:39 2008 Subject: [Haskell-cafe] Re: Philip Wadler video on Howard-Curry Correspondence ??? References: <5ae4f2ba0811262148y1054a725wbf217dbbfc6334f3@mail.gmail.com> Message-ID: <7u0ti4tr9lq6sugpfac29cuvtuleq4gkl1@4ax.com> On Wed, 26 Nov 2008 23:48:19 -0600, "Galchin, Vasili" wrote: >Hello, > > I am reading re-reading Prof. Wadler paper Proofs are Programs: 19th >Century Logic and 21st Century Computing >but also want to re-read watch his video on same subject..... > >??? There is a reference to the video in question at the following site, but the link seems to be broken: Proofs are Programs: 19th Century Logic and 21st Century Computing | Lambda the Ultimate http://lambda-the-ultimate.org/node/1447 The same link is also mentioned at the following site as well: Wadler: History of logic and programming languages http://homepages.inf.ed.ac.uk/wadler/topics/history.html The (broken) link mentioned at the above two sites is the following: TechNetCast Archives http://technetcast.ddj.com/tnc_catalog.html?item_id=1011 However, attempting to visit the above-mentioned site results in the following error message: > Query Failed1 Since the same URL is mentioned at both sites, this error is unlikely to be the result of a typo. Perhaps either the item was removed, or the hosting server is down? You may wish to try reaching the contact person for the site hosting the video, Dr. Dobb's TechNetCast (see http://technetcast.ddj.com/), at editors@ddj.com. -- Benjamin L. Russell From simonpj at microsoft.com Thu Nov 27 06:36:27 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Nov 27 06:30:11 2008 Subject: [Haskell-cafe] Proposal for associated type synonyms in Template Haskell In-Reply-To: <52f14b210811110311v8ab419au5f33b08b9681f84d@mail.gmail.com> References: <49104B62.5010308@cs.ru.nl> <491052AB.2010302@cs.ru.nl> <4b39c80a0811040600y16257eafh5037a851284af10e@mail.gmail.com> <4911B442.7080104@cs.ru.nl> <52f14b210811110311v8ab419au5f33b08b9681f84d@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33281447EE7@EA-EXMSG-C334.europe.corp.microsoft.com> I've been away. I hope others will reply to this thread too; whatever you decide will end up in TH indefinitely. I know that Roman is interested in this. ? You focus just on type families in class declarations (which is indeed where associated types started). But I suggest you also allow them at top level, as GHC does using the syntax type family T a :: * Indeed, since you propose to add to Dec, that'll happen automatically. But perhaps "AssocTySynKindD" is not a good name. Perhaps "TySynFamilyD"? ? GHC uses type instance T [a] = Tree a as the way to add an equation to the definition of T. So perhaps "TySynInstance" rather than "AssocTySynD"? ? I agree that it'd be good to do data type/newtype families at the same time. Roman needs this. ? Your proposal for kinds looks fine. Simon From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Jos? Pedro Magalh?es Sent: 11 November 2008 11:11 To: Haskell Cafe Subject: Re: [Haskell-cafe] Proposal for associated type synonyms in Template Haskell Hello Thomas, I see this is a proposal for a partial implementation of #1673 (http://hackage.haskell.org/trac/ghc/ticket/1673). Maybe it would be good if the remaining syntax (associated datatypes and type families) would also be defined and implemented in TH. Or maybe there isn't much demand for this?... Cheers, Pedro On Wed, Nov 5, 2008 at 15:57, Thomas van Noort > wrote: Hello, Recently, we released a library on Hackage for generic rewriting (package "rewriting" if you are curious). The user of the library is expected to define type class instances to enable rewriting on his or her own datatypes. As these instances follow the datatype declarations closely, we tried to generate the instances using Template Haskell. Unfortunately, associated type synonyms are not yet supported by TH. After a presentation at the WGP'08, Simon encouraged us to write a proposal about adding associated type synonyms to TH, so that it can be added to GHC. So, here is our proposal. The TH AST must allow 1) kind declarations of associated type synonyms in class declarations and 2) their definitions in instance declarations. For example, class Foo a where type Bar a :: * instance Foo Int where type Bar Int = String The TH library defines a datatype Dec which contains a constructor for class declarations and instance declarations: data Dec = ... | ClassD Cxt Name [Name] [FunDep] [Dec] | InstanceD Cxt Type [Dec] ... 1) Associated type synonym kind declarations We suggest to add a constructor to the Dec type: ... | AssocTySynKindD Name [Name] (Maybe Kind) ... assocTySynKindD :: Name -> [Name] -> Maybe KindQ -> DecQ The first field is the name of the associated type synonym, the second field is a list of type variables, and the third field is an optional kind. Since kinds are not yet defined in TH, we have to add some kind of kind definition (pun intended): data Kind = StarK | ArrowK Kind Kind type KindQ = Q Kind starK :: KindQ arrowK :: KindQ -> KindQ -> KindQ We explicitly choose not to reuse the Type type to define kinds (i.e., type Kind = Type as in GHC) since we think a separation between the two worlds is much clearer to the users of TH. 2) Associated type synonym definitions We suggest to add another constructor to the Dec type: ... | AssocTySynD Name [Type] Type ... assocTySynD :: Name -> [TypeQ] -> TypeQ -> DecQ The first field is the name of the type synonym, the second field is a list of type arguments, and the third field is the body of the type synonym. We would like to hear your comments to this proposal. Regards, Thomas _______________________________________________ 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/20081127/efafce24/attachment.htm From DekuDekuplex at Yahoo.com Thu Nov 27 06:51:29 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Thu Nov 27 06:45:24 2008 Subject: [Haskell-cafe] Re: Philip Wadler video on Howard-Curry Correspondence ??? References: <5ae4f2ba0811262148y1054a725wbf217dbbfc6334f3@mail.gmail.com> <7u0ti4tr9lq6sugpfac29cuvtuleq4gkl1@4ax.com> Message-ID: Incidentally, Haskell is mentioned several times in the Dr. Dobbs Journal article on the Wadler paper: Dr. Dobb's | Old ideas form the basis of advancements in functional programming | 12 1, 2000 http://www.ddj.com/showArticle.jhtml?articleID=184404384 Specifically: >Languages that took more direct inspiration from lambda calculus include: > >... > >Haskell, named for Haskell Curry (Hudak, Peyton Jones, Wadler, and others, 1987; see http://haskell.org/). and >Standard ML is noted for its exploration of module types, Haskell for its type classes, and O'Caml for its object-oriented types. Standard ML, Haskell, and O'Caml are all continuing development, and innovation in their type systems is one of the principal directions of research. and >Applications built on top of functional languages, and which themselves use type systems in innovative ways, include: ... Lolita, a natural language understanding system (implemented in Haskell) ... and >... Yarrow in Haskell (http://www.cs.kun.nl/~janz/ yarrow/) ... The article discusses the impact of logic on functional programming, citing examples including those involving Haskell, and mentions a correspondence between types and proofs. -- Benjamin L. Russell On Thu, 27 Nov 2008 20:33:37 +0900, Benjamin L.Russell wrote: >On Wed, 26 Nov 2008 23:48:19 -0600, "Galchin, Vasili" > wrote: > >>Hello, >> >> I am reading re-reading Prof. Wadler paper Proofs are Programs: 19th >>Century Logic and 21st Century Computing >>but also want to re-read watch his video on same subject..... >> >>??? > >There is a reference to the video in question at the following site, >but the link seems to be broken: > >Proofs are Programs: 19th Century Logic and 21st Century Computing | >Lambda the Ultimate >http://lambda-the-ultimate.org/node/1447 > >The same link is also mentioned at the following site as well: > >Wadler: History of logic and programming languages >http://homepages.inf.ed.ac.uk/wadler/topics/history.html > >The (broken) link mentioned at the above two sites is the following: > >TechNetCast Archives >http://technetcast.ddj.com/tnc_catalog.html?item_id=1011 > >However, attempting to visit the above-mentioned site results in the >following error message: > >> Query Failed1 > >Since the same URL is mentioned at both sites, this error is unlikely >to be the result of a typo. > >Perhaps either the item was removed, or the hosting server is down? >You may wish to try reaching the contact person for the site hosting >the video, Dr. Dobb's TechNetCast (see http://technetcast.ddj.com/), >at editors@ddj.com. > >-- Benjamin L. Russell From a.d.clark at ed.ac.uk Thu Nov 27 06:52:04 2008 From: a.d.clark at ed.ac.uk (allan) Date: Thu Nov 27 06:46:08 2008 Subject: [Haskell-cafe] haddock question Message-ID: <492E89E4.1080703@ed.ac.uk> Dear all I'm trying to locally build the documentation for the haskell-src-exts package and running into a bit of bother. If I run: cabal haddock I get the error: haddock: parse error in doc string so: cabal haddock -v Doesn't really provide any extra information, it gives me the exact haddock command-line used but there is still no way (I can see) of obtaining the source file containing the parse error. So I downloaded via darcs the latest haddock source code and installed that but I get the exact same error message. I tried grepping in the haddock source code for that particular error message (and portions of it) but I couldn't find it. Finally I tried running haddock on a single source file: haddock Language/Haskell/Exts.hs and even this gets the exact same error message, which is somewhat bizarre since that file does not contain any documentation strings. Anyone have any ideas? regards allan -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From olivier.boudry at gmail.com Thu Nov 27 06:58:57 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Thu Nov 27 06:52:38 2008 Subject: [Haskell-cafe] Re: Problem getting code from AFP08 parallel tutorial to run in parallel In-Reply-To: <20081125220703.GK14812@scytale.galois.com> References: <20081124185140.GC7952@scytale.galois.com> <492C06B4.4030401@gmail.com> <20081125220703.GK14812@scytale.galois.com> Message-ID: On Tue, Nov 25, 2008 at 11:07 PM, Don Stewart wrote: > What does the code look like? It looks like that. Of course it doesn't compute the same number as the initial code, but it starts 3 sparks and I get the expected 100% CPU usage instead of 50%. parSumFibEuler :: Int -> Int -> Int -> Int parSumFibEuler a b c = f `par` (e `par` (g `pseq` (f + e + g))) where f = fib a e = sumEuler b g = sumEuler c r1 :: Int r1 = parSumFibEuler 40 7450 7449 Instead of: parSumFibEuler :: Int -> Int -> Int parSumFibEuler a b = f `par` (e `pseq` (f + e)) where f = fib a e = sumEuler b r1 :: Int r1 = parSumFibEuler 40 7450 Olivier. From josef.svenningsson at gmail.com Thu Nov 27 07:09:41 2008 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Thu Nov 27 07:03:22 2008 Subject: [Haskell-cafe] Philip Wadler video on Howard-Curry Correspondence ??? In-Reply-To: <5ae4f2ba0811262148y1054a725wbf217dbbfc6334f3@mail.gmail.com> References: <5ae4f2ba0811262148y1054a725wbf217dbbfc6334f3@mail.gmail.com> Message-ID: <8dde104f0811270409o4f79c80y4ddec122052b527f@mail.gmail.com> 2008/11/27 Galchin, Vasili : > Hello, > > I am reading re-reading Prof. Wadler paper > > Proofs are Programs: 19th Century Logic and 21st Century Computing > > but also want to re-read watch his video on same subject..... > Is it this talk you're after? http://video.google.com/videoplay?docid=-4167170843018186532&ei=sI0uSZT7Faf22gKd9NTqDQ&q=wadler+philip Cheers, Josef From aneumann at inf.fu-berlin.de Thu Nov 27 07:12:32 2008 From: aneumann at inf.fu-berlin.de (Adrian Neumann) Date: Thu Nov 27 07:06:48 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <20081127082346.GC20722@scytale.galois.com> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DBFC7.20602@pikewerks.com> <492DC105.5010803@btinternet.com> <20081126215834.GA12265@petunia.outback.escape.de> <42EE2A3F-C3C1-4D08-A024-8214A66B0F1A@ece.cmu.edu> <20081127082346.GC20722@scytale.galois.com> Message-ID: <03A9D55A-FFF7-4973-99C0-3EC1516608A8@inf.fu-berlin.de> Am 27.11.2008 um 09:23 schrieb Don Stewart: > allbery: >> On 2008 Nov 26, at 16:58, Matthias Kilian wrote: >>> On Wed, Nov 26, 2008 at 09:35:01PM +0000, Andrew Coppin wrote: >>>>> It is a fork of the JHC compiler, which should be easier to >>>>> look up. >>>>> There is also Hugs, as you mentioned. In addition, you may want to >>>>> look at YHC and NHC. >>>> >>>> Yeah, the "implementations" page on the Wiki basically says that >>>> there's >>>> GHC and Hugs, and there's also these things called YHC, NHC and >>>> JHC. All >>>> the documentation I've read makes these latter compilers sound >>>> highly >>>> experimental and unusable. >>> >>> I would't call nhc experimental; it's quite usable, at least for >>> standard Haskell-98 stuff (plus some language extensions). >> >> >> On a related topic: whatever happened to the compiler shootout? >> (Aside from dons leaving unsw) > > Malcolm continues the tradition, > > http://code.haskell.org/nobench/ All result links are broken. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: Signierter Teil der Nachricht Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20081127/6eb32ba9/PGP.bin From ross at soi.city.ac.uk Thu Nov 27 07:25:43 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Nov 27 07:19:26 2008 Subject: [Haskell-cafe] haddock question In-Reply-To: <492E89E4.1080703@ed.ac.uk> References: <492E89E4.1080703@ed.ac.uk> Message-ID: <20081127122543.GA3132@soi.city.ac.uk> On Thu, Nov 27, 2008 at 11:52:04AM +0000, allan wrote: > I'm trying to locally build the documentation for the haskell-src-exts package and running into a bit of bother. > If I run: cabal haddock > I get the error: > haddock: parse error in doc string The problem is that several of the modules (not Language.Haskell.Exts, but modules it imports) have headers containing a field "Original" that haddock doesn't recognize. Of course the lack of any location information in the error message is a deficiency in haddock. From a.d.clark at ed.ac.uk Thu Nov 27 07:42:20 2008 From: a.d.clark at ed.ac.uk (allan) Date: Thu Nov 27 07:36:12 2008 Subject: [Haskell-cafe] haddock question [solved] In-Reply-To: <20081127122543.GA3132@soi.city.ac.uk> References: <492E89E4.1080703@ed.ac.uk> <20081127122543.GA3132@soi.city.ac.uk> Message-ID: <492E95AC.5020605@ed.ac.uk> Ross Paterson wrote: > On Thu, Nov 27, 2008 at 11:52:04AM +0000, allan wrote: >> I'm trying to locally build the documentation for the haskell-src-exts package and running into a bit of bother. >> If I run: cabal haddock >> I get the error: >> haddock: parse error in doc string > > The problem is that several of the modules (not Language.Haskell.Exts, > but modules it imports) have headers containing a field "Original" > that haddock doesn't recognize. > a ha, Thank you, that has fixed the problem. regards allan -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From and1 at meinungsverstaerker.de Thu Nov 27 08:11:52 2008 From: and1 at meinungsverstaerker.de (And1) Date: Thu Nov 27 08:05:32 2008 Subject: [Haskell-cafe] HaskellWiki image upload fails because of - probably - the filesize. Message-ID: <20081127131152.GA27497@meinungsverstaerker.de> Hey dear Haskell-Cafe-Readers, I tried several times to upload several images - screenshots that is - to my HaskellWiki/Xmonad site: http://haskell.org/haskellwiki/Image:And1_xmonad.png I always get the error, that the connection to the site/server was reset. I mailed both administrators of the HaskellWiki but I got, for about 2-4 weeks now, no reply. I tried to upload the following images, maybe that's important: http://and1.donnergurgler.net/misc/screen_2008-09-26.png http://and1.donnergurgler.net/misc/screen_2008-11-02.png http://and1.donnergurgler.net/misc/screen_2008-11-10.png I was told, that the problem is maybe the filesize of the new images, because it is bigger, then the filesize of the image already uploaded. Thanks for reading this and hopefully finding the problem, -- Regards, Andi R. From tphyahoo at gmail.com Thu Nov 27 08:32:15 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Thu Nov 27 08:25:55 2008 Subject: pbkdf2 on hackage Re: Re[2]: [Haskell-cafe] Password hashing Message-ID: <910ddf450811270532n891cdfdw81effaebc1c5e87@mail.gmail.com> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/PBKDF2 Since no one took up my code review request I just did the best I could and uploaded to hackage. There were indeed some mistakes in my initial post, fixed now. (Code review is still wished, though!) Alas, documentation doesn't build with hackage, altough it does for me locally. (Seems like almost everything I do these days -- what am I doing wrong?!) Also I'm open to folding this into a more established crypto package if there are any takers... psst, dominic. Also, dominic, shouldn't your crypto package be added to category Cryptography (a cabal file change) so it lists aside the other crypto packages? thanks, thomas. 2008/11/26 Thomas Hartman : > Sorry about the hideous formatting above. Reattached as a text file. > > t. > > 2008/11/26 Thomas Hartman : >> OK, I went ahead and implemented pbkdf2, following the algorithm >> linked to by bulat and Michael. >> >> If there are any crypto gurus who can code-review this I would be much >> obliged, and when I'm confident enough that this does the right thing >> I'll put it up on hackage. >> >> I don't do much crypto so this *definitely* needs a review before it >> becomes a library? >> >> How's this looks, cafe? >> >> Thanks! >> >> Thomas. >> >> >> {-# LANGUAGE ScopedTypeVariables #-} >> module Crypto.PBKDF2 (pbkdf2, pbkdf2') where >> >> import qualified Data.ByteString.Char8 as B >> import qualified Data.ByteString.Lazy as L >> import GHC.Word >> import Control.Monad (foldM) >> import Random >> import Data.Digest.SHA512 (hash) >> import Data.Word >> import Data.Bits >> import Data.Binary >> >> newtype Password = Password [Word8] >> newtype Salt = Salt [Word8] >> newtype HashedPass = HashedPass [Word8] >> deriving Show >> {- | A reasonable default for rsa pbkdf2? Actually I'm not really >> sure, ask folk with more experience. >> >>> pbkdf2 = pbkdf2' prfSHA512 512 512 512 >> -} >> t = pbkdf2 ( Password . toWord8s $ "meh" ) ( Salt . toWord8s $ "moo" ) >> pbkdf2 :: Password -> Salt -> HashedPass >> pbkdf2 = pbkdf2' prfSHA512 512 512 512 >> >> {- | Password Based Key Derivation Function, from RSA labs. >> >>> pbkdf2' prf hlen cIters dklen (Password pass) (Salt salt) >> -} >> pbkdf2' :: ([Word8] -> [Word8] -> [Word8]) -> Integer -> Integer -> >> Integer -> Password -> Salt -> HashedPass >> pbkdf2' prf hlen cIters dklen (Password pass) (Salt salt) >> | dklen > ( (2^32-1) * hlen) = error $ "pbkdf2, (dklen,hlen) : " ++ >> (show (dklen,hlen)) >> | otherwise = >> let --l,r :: Int >> l = ceiling $ (fromIntegral dklen) / (fromIntegral hlen ) >> r = dklen - ( (l-1) * hlen) >> ustream :: [Word8] -> [Word8] -> [[Word8]] >> ustream p s = let x = prf p s >> in x : ustream p x >> --us :: Integer -> [[Word8]] >> us i = take (fromIntegral cIters) $ ustream pass ( salt `myor` >> ((intToFourWord8s i) )) >> --f :: [Word8] -> [Word8] -> Integer -> Integer -> [Word8] >> f pass salt cIters i = foldr1 myxor $ us i >> ts :: [[Word8]] >> ts = map (f pass salt cIters) ( [1..l] ) >> in HashedPass . take (fromIntegral dklen) . concat $ ts >> >> -- The spec says >> -- Here, INT (i) is a four-octet encoding of the integer i, most >> significant octet first. >> -- I'm reading from the right... is this the right thing? >> toWord8s x = L.unpack . encode $ x >> >> --intToFourWord8s :: Integer -> [Word8] >> intToFourWord8s i = let w8s = toWord8s $ i >> in drop (length w8s -4) w8s >> >> myxor :: [Word8] -> [Word8] -> [Word8] >> myxor = zipWith xor >> >> myor :: [Word8] -> [Word8] -> [Word8] >> myor = zipWith (.|.) >> >> prfSHA512 :: [Word8] -> [Word8] -> [Word8] >> prfSHA512 x y = hash $ x ++ y >> >> >> 2008/11/26 John Meacham : >>> What you are using there is not a salt, but rather a secret key. The >>> important thing about a salt is that it is different for _every user_. >>> and you actually store the salt unhashed along with the hash. (it is not >>> secret information). A salt protects against a dictionary attack, for >>> instance, you might have a dictionary of hash's and the common passwords >>> they go to but if you add a 32 bit salt, you would need 2^32 entries for >>> each dictionary word, making such an attack unworkable. You can also >>> trivially tell if two users have the _same_ password just by comparing >>> the hashes without a salt. >>> >>> John >>> >>> -- >>> John Meacham - ?repetae.net?john? >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> > From daniel.yokomizo at gmail.com Thu Nov 27 08:43:08 2008 From: daniel.yokomizo at gmail.com (Daniel Yokomizo) Date: Thu Nov 27 08:36:48 2008 Subject: [Haskell-cafe] Need machine for DPH benchmarking In-Reply-To: <37006B2E-B4CF-46F9-9420-61A556B3DF4A@cse.unsw.edu.au> References: <37006B2E-B4CF-46F9-9420-61A556B3DF4A@cse.unsw.edu.au> Message-ID: On Thu, Nov 27, 2008 at 5:45 AM, Roman Leshchinskiy wrote: > Hi all, > > we, the DPH team, are at the moment in the very unfortunate situation of not > having a proper machine for running our benchmarks on. Could a kind soul > maybe give us (i.e., me) access to a quadcore or 2xquadcore x86 Linux or OS > X machine? I only need to build ghc on it and run small benchmarks which > never take more than a couple of minutes, maybe once every couple of days or > so. We do need to use all cores, though, so no other CPU-intensive processes > can be running during benchmarking. This is only for a week or two, until we > get our own machine. We would be eternally grateful and won't forget you > when DPH takes over the world. Another possibility is using the Amazon EC2 functionality and rent a high-CPU instance (http://aws.amazon.com/ec2/#instance) for as long as you need. An extra large high-CPU instance costs $0.80 per hour (http://aws.amazon.com/ec2/#pricing), is an 8-core machine, you only pay for the time used and it runs any kind of Linux you want (there are dozens of already configured instances with different configurations, it's also possible to configure your own). I've been using it for a few months and have no complaints. > Roman Best regards, Daniel Yokomizo From marlowsd at gmail.com Thu Nov 27 08:51:05 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 27 08:44:49 2008 Subject: [Haskell-cafe] Re: catting to cat gets stuck at > 135K In-Reply-To: References: <42784f260811101329o6fde82f5x1a9636e4cd8ba948@mail.gmail.com> <5558E5DB-A741-4FF9-8596-FC70BC9BF835@ece.cmu.edu> <42784f260811101604q595bfaeam1c07d1a918fca7cd@mail.gmail.com> Message-ID: <492EA5C9.7050803@gmail.com> Brandon S. Allbery KF8NH wrote: > > On 2008 Nov 10, at 19:04, Jason Dusek wrote: > >>>> simple exe bytes args = do >>>> (i, o, e, p) <- runInteractiveProcess exe args Nothing >>>> Nothing >>>> hPut i bytes >>>> s <- hGetContents o >>>> hClose i >>>> return s >>> >>> Yep, that's your problem. forkIO the hPut. >> >> Maybe I didn't do enough here -- just wrapping in `forkIO` >> does not seem to actually help. > > > *sigh* I hate the ghc runtime... it works in ghci, or compiled with > -threaded. Would you hate it less if -threaded were the default? > Otherwise you still get the deadlock because it only > switches threads under limited circumstances (garbage collections?) No, the issue is that without real OS threads, a foreign call can't be pre-empted (pretty obvious when you think about it). waitForProcess ends up making a blocking foreign call - non-obvious, but at least it's documented. Cheers, Simon From marlowsd at gmail.com Thu Nov 27 09:19:04 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 27 09:12:48 2008 Subject: [Haskell-cafe] Re: Go Haskell! In-Reply-To: References: <1226399902.6496.9.camel@rubix.office.last.fm><9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com> Message-ID: <492EAC58.5080207@gmail.com> Claus Reinke wrote: >> Do you have an example of a mutable state/ IO bound application, like, >> hmm, a window manager or a revision control system or a file system...? > > If you're looking for a challenge, how about this one (there used to > be lots of Haskellers into this game, any of you still around?-): > > http://computer-go.org/pipermail/computer-go/2008-October/016680.html [ catching up with old haskell-cafe email ] Interestingly, I did this a while ago. Here's my results: $ ./Bench 1 100000 b: 14840, w: 17143 mercy: 67982 elapsed time: 3.42s playouts/sec: 29208 so, nearly 30k/sec random playouts on 9x9. That's using a hack that stops the game when the score is heavily in favour of one player, it drops to around 20k/sec with that turned off. Not bad, but probably I'd guess an order of magnitude worse than you can do in tightly-coded C. The Haskell implementation isn't nice, as you predicted. Also the code is derived from some non-free internal MS code, so unfortunately I can't share it (but I could perhaps extract the free bits if anyone is really interested). W wins slightly more often I think because komi 5.5 on a 9x9 board is a tad high. It does parallelise too, of course: $ ./Bench 8 100000 +RTS -N8 b: 14872, w: 17488 mercy: 67584 elapsed time: 1.00s playouts/sec: 99908 though still room for improvement there. Cheers, Simon From bulat.ziganshin at gmail.com Thu Nov 27 09:25:38 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Nov 27 09:23:26 2008 Subject: [Haskell-cafe] Need machine for DPH benchmarking In-Reply-To: References: <37006B2E-B4CF-46F9-9420-61A556B3DF4A@cse.unsw.edu.au> Message-ID: <1965691213.20081127172538@gmail.com> Hello Daniel, Thursday, November 27, 2008, 4:43:08 PM, you wrote: > Another possibility is using the Amazon EC2 functionality and rent a > high-CPU instance (http://aws.amazon.com/ec2/#instance) for as long as these are virtual cores, which isn't appropriate for measuring performance on real 4/8 core boxes -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ndmitchell at gmail.com Thu Nov 27 09:38:48 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Nov 27 09:32:29 2008 Subject: [Haskell-cafe] Possible issue with Hoogle and Haddock? In-Reply-To: References: <50b5ae760811201125i15b723a9hbb972b67287f909b@mail.gmail.com> <20081121010833.GA7508@matrix.chaos.earth.li> Message-ID: <404396ef0811270638m58982952xfc79dde298e4434c@mail.gmail.com> Hi Stephen, I've now worked around this bug in Hoogle - I'm just about to rebuild the website, and hopefully the bug will have disappeared. (Rebuilding the website could take a few days, as I'm currently hunting for the right compiler etc...) Thanks Neil On Fri, Nov 21, 2008 at 8:21 AM, Mitchell, Neil wrote: > >> > I was noticing recently that there seems to be a problem >> with Hoogle >> > and Haddock. In particular, I just hoogled "bracket" and got the >> > following result: >> > bracket :: IO a -> a -> IO b -> a -> IO c -> IO c >> Clearly this is the >> > wrong type, as it should be >> > bracket :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c >> > >> > Is this a bug? Is is something that's well-known? >> >> Yes, it's a known bug: >> http://hackage.haskell.org/trac/ghc/ticket/2584 > > I can make a work around for Hoogle (well, I can write a workaround in > the Hoogle specific code of Haddock), but was hoping that the bug would > be fixed before 6.10. I guess its now worth making the Hoogle specific > fix. > > Thanks > > Neil > > ============================================================================== > Please access the attached hyperlink for an important electronic communications disclaimer: > > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > ============================================================================== > > From daniel.yokomizo at gmail.com Thu Nov 27 09:47:42 2008 From: daniel.yokomizo at gmail.com (Daniel Yokomizo) Date: Thu Nov 27 09:41:22 2008 Subject: [Haskell-cafe] Need machine for DPH benchmarking In-Reply-To: <1965691213.20081127172538@gmail.com> References: <37006B2E-B4CF-46F9-9420-61A556B3DF4A@cse.unsw.edu.au> <1965691213.20081127172538@gmail.com> Message-ID: On Thu, Nov 27, 2008 at 12:25 PM, Bulat Ziganshin wrote: > Hello Daniel, > > Thursday, November 27, 2008, 4:43:08 PM, you wrote: > >> Another possibility is using the Amazon EC2 functionality and rent a >> high-CPU instance (http://aws.amazon.com/ec2/#instance) for as long as > > these are virtual cores, which isn't appropriate for measuring > performance on real 4/8 core boxes That's why I mentioned it as another possibility. It won't give you performance numbers for a specific processor but you can run tests to see parallelization behavior and get some food for thought. It's a pretty cheap way to explore ideas if you don't have a equivalent machine available. > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com Best regards, Daniel Yokomizo From claus.reinke at talk21.com Thu Nov 27 10:51:33 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Nov 27 10:45:20 2008 Subject: [Haskell-cafe] Re: Go Haskell! References: <1226399902.6496.9.camel@rubix.office.last.fm><9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com> <492EAC58.5080207@gmail.com> Message-ID: <718AAA7EDD8244709E670ACE86B80C29@cr3lt> >>> Do you have an example of a mutable state/ IO bound application, like, >>> hmm, a window manager or a revision control system or a file system...? >> If you're looking for a challenge, how about this one (there used to >> be lots of Haskellers into this game, any of you still around?-): >> http://computer-go.org/pipermail/computer-go/2008-October/016680.html > Interestingly, I did this a while ago. Here's my results: > > $ ./Bench 1 100000 > b: 14840, w: 17143 mercy: 67982 > elapsed time: 3.42s > playouts/sec: 29208 > > so, nearly 30k/sec random playouts on 9x9. That's using a hack that stops > the game when the score is heavily in favour of one player, it drops to > around 20k/sec with that turned off. Nice!-) 20k playouts/sec (without the early cutoffs) is the rough number usually mentioned for these light playouts, reachable even in Java. My own Haskell code for that was a factor of 5 slower:-( > Not bad, but probably I'd guess an order of magnitude worse than you > can do in tightly-coded C. Yes, a few people have reported higher rates, but most hobby coders seem happy with 20k/sec - after that, it seems more interesting to move towards heavy playouts and combinations with tree-based search instead of light playouts with simple statistics alone. But if you don't get at least those 20k/sec, it is difficult to run the number of experiments needed to test presumed improvements in playing strength. > The Haskell implementation isn't nice, as you predicted. What is really annoying for me is that I'm no longer used to this low-level style of coding, so every time I add something, performance goes down, and I have to work to get it back (I modified my playout code to match that reference bot specification - my bot does get the expected 50% wins against jrefbot, but is now a factor of 8 slower (still using only half the memory, though)). Not to mention that I'm throwing away many of the advantages of Haskell. That is one reason why I mentioned this challenge. > Also the code is derived from some non-free internal MS code, > so unfortunately I can't share it (but I could perhaps extract the free > bits if anyone is really interested). Interesting, can you tell what kind of code those internal bits are? Of course, the fun is implementing it oneself, but it is very useful to have reference points, such as the refbot spec, or the Java implementation to play against. Your Haskell reference point will spur me to have another look at my bot's performance!-) The Go programming folks have a lot of useful infrastructure, btw, including a server just for bot-vs-bot competition: http://cgos.boardspace.net/ Not to mention monthly tournaments, competions, etc. > It does parallelise too, of course: > > $ ./Bench 8 100000 +RTS -N8 > b: 14872, w: 17488 mercy: 67584 > elapsed time: 1.00s > playouts/sec: 99908 > > though still room for improvement there. That is the other reason why I mentioned this challenge: the specs people use for their competition bots are interestingly parallel. One example, this year's Computer Go Olympiad results: http://www.grappa.univ-lille3.fr/icga/tournament.php?id=181 Many Faces of Go, winner, currently maxes out at 32 cores, a limitation its author would like to remove (he's working with the Microsoft HPC group, btw). For the exhibition game against a pro that made the news this year, MoGo used a cluster of 800 cores: http://www.mail-archive.com/computer-go@computer-go.org/msg08692.html http://www.mail-archive.com/computer-go@computer-go.org/msg08710.html Of course, the simple reference bot implementations are a far cry from MoGo or ManyFaces, but I thought this would be an interesting non-trivial-but-doable challenge for Haskell performance and parallelism fans, especially since there are still many people interested in Go here;-) Claus From allbery at ece.cmu.edu Thu Nov 27 11:38:35 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Nov 27 11:32:21 2008 Subject: [Haskell-cafe] Re: catting to cat gets stuck at > 135K In-Reply-To: <492EA5C9.7050803@gmail.com> References: <42784f260811101329o6fde82f5x1a9636e4cd8ba948@mail.gmail.com> <5558E5DB-A741-4FF9-8596-FC70BC9BF835@ece.cmu.edu> <42784f260811101604q595bfaeam1c07d1a918fca7cd@mail.gmail.com> <492EA5C9.7050803@gmail.com> Message-ID: <00034B2E-5008-4489-855C-D5AD524509FB@ece.cmu.edu> On 2008 Nov 27, at 8:51, Simon Marlow wrote: > Brandon S. Allbery KF8NH wrote: >> On 2008 Nov 10, at 19:04, Jason Dusek wrote: >>>>> simple exe bytes args = do >>>>> (i, o, e, p) <- runInteractiveProcess exe args Nothing >>>>> Nothing >>>>> hPut i bytes >>>>> s <- hGetContents o >>>>> hClose i >>>>> return s >>>> >>>> Yep, that's your problem. forkIO the hPut. >>> >>> Maybe I didn't do enough here -- just wrapping in `forkIO` >>> does not seem to actually help. >> *sigh* I hate the ghc runtime... it works in ghci, or compiled with >> -threaded. > > Would you hate it less if -threaded were the default? > >> Otherwise you still get the deadlock because it only switches >> threads under limited circumstances (garbage collections?) > > No, the issue is that without real OS threads, a foreign call can't > be pre-empted (pretty obvious when you think about it). > waitForProcess ends up making a blocking foreign call - non-obvious, > but at least it's documented. The way this is usually handled in the non-threaded case is to either use SIGCHLD or non-blocking waitpid() so that "green" threads can continue running. I'm a little surprised this wasn't done. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From gwern0 at gmail.com Thu Nov 27 11:58:34 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Thu Nov 27 11:52:21 2008 Subject: [Haskell-cafe] HaskellWiki image upload fails because of - probably - the filesize. In-Reply-To: <20081127131152.GA27497@meinungsverstaerker.de> References: <20081127131152.GA27497@meinungsverstaerker.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, Nov 27, 2008 at 8:11 AM, And1 wrote: > Hey dear Haskell-Cafe-Readers, > > I tried several times to upload several images - screenshots that is - to > my HaskellWiki/Xmonad site: > > http://haskell.org/haskellwiki/Image:And1_xmonad.png > > I always get the error, that the connection to the site/server was > reset. > > I mailed both administrators of the HaskellWiki but I got, for about 2-4 > weeks now, no reply. > > I tried to upload the following images, maybe that's important: > > http://and1.donnergurgler.net/misc/screen_2008-09-26.png > http://and1.donnergurgler.net/misc/screen_2008-11-02.png > http://and1.donnergurgler.net/misc/screen_2008-11-10.png > > I was told, that the problem is maybe the filesize of the new images, > because it is bigger, then the filesize of the image already uploaded. > > Thanks for reading this and hopefully finding the problem, Size would not be the issue; I've uploaded multimegabyte tarballs in the past. I tried uploading one of your images and the connection fails immediately, so it looks to me also like there is a problem in the MediaWiki server. - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkku0bIACgkQvpDo5Pfl1oKSBACdF02Vmze2gi4CSJmjswxxEnmj orIAnRLzgng1xB6/urdCT4Kkb+e5Z0TR =tatY -----END PGP SIGNATURE----- From igloo at earth.li Thu Nov 27 12:20:08 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Nov 27 12:13:48 2008 Subject: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs In-Reply-To: <1227738501.19577.42.camel@localhost> References: <20081126143832.GC15463@brighton.ac.uk> <1227738501.19577.42.camel@localhost> Message-ID: <20081127172008.GA20810@matrix.chaos.earth.li> On Wed, Nov 26, 2008 at 10:28:21PM +0000, Duncan Coutts wrote: > On Wed, 2008-11-26 at 14:38 +0000, Eric Kow wrote: > > > > Older versions of darcs can to produce gzipped files with broken CRCs. > > We never noticed this because our homegrown wrapper around the C libz > > library does not pick up these errors. > > I should note that one moral of this story is to check that your FFI > imports are correct. That is, check they import the foreign functions at > the right Haskell types. In this case the mistake was that the foreign > function returned a C int, but the Haskell foreign import declaration > stated that the C function returned IO () rather than IO CInt. While that's true, Haskell also makes it easy to make the same sort of error with IO (or any other Monad) values, whether created with the FFI or not. If you say f = do x y z and y has type IO CInt then you won't get an error (and I don't think you can even ask for a warning with the current implementations). Should we have (>>) :: (Monad m) => m () -> m a -> m a and force you to write _ <- y ? Thanks Ian From lrpalmer at gmail.com Thu Nov 27 12:27:48 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Nov 27 12:21:28 2008 Subject: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs In-Reply-To: <20081127172008.GA20810@matrix.chaos.earth.li> References: <20081126143832.GC15463@brighton.ac.uk> <1227738501.19577.42.camel@localhost> <20081127172008.GA20810@matrix.chaos.earth.li> Message-ID: <7ca3f0160811270927p4c7f8ac2rd301810acdb9c5a@mail.gmail.com> On Thu, Nov 27, 2008 at 10:20 AM, Ian Lynagh wrote: > On Wed, Nov 26, 2008 at 10:28:21PM +0000, Duncan Coutts wrote: >> On Wed, 2008-11-26 at 14:38 +0000, Eric Kow wrote: >> > >> > Older versions of darcs can to produce gzipped files with broken CRCs. >> > We never noticed this because our homegrown wrapper around the C libz >> > library does not pick up these errors. >> >> I should note that one moral of this story is to check that your FFI >> imports are correct. That is, check they import the foreign functions at >> the right Haskell types. In this case the mistake was that the foreign >> function returned a C int, but the Haskell foreign import declaration >> stated that the C function returned IO () rather than IO CInt. > > While that's true, Haskell also makes it easy to make the same sort of > error with IO (or any other Monad) values, whether created with the FFI > or not. If you say > > f = do x > y > z > > and y has type IO CInt then you won't get an error (and I don't think > you can even ask for a warning with the current implementations). > > Should we have > (>>) :: (Monad m) => m () -> m a -> m a > and force you to write > _ <- y > ? I'd like that (though I certainly didn't like that prospect when I started learning). I think the option of turning on a warning would be a nice happy medium. Luke From pkeir at dcs.gla.ac.uk Thu Nov 27 12:57:57 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Thu Nov 27 12:51:40 2008 Subject: [Haskell-cafe] followedBy parser in Parsec Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80CCB00@EX2.ad.dcs.gla.ac.uk> Hi, Is there a way in Parsec to check what the next token is, and if it is what you're hoping for, leave it there. This is an example of something which doesn't work at all: testpar = try $ do ae <- array_element option [] $ try $ satisfy (\c -> c /= '(') >> unexpected "" return ae I'm finding this totally confusing by now %0 Can I invert "notFollowedBy" somehow, or maybe there's a "peek" function I don't know about? Help! Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081127/46301d0e/attachment.htm From claus.reinke at talk21.com Thu Nov 27 12:59:42 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Nov 27 12:57:05 2008 Subject: [Haskell-cafe] Re: Go Haskell! References: <1226399902.6496.9.camel@rubix.office.last.fm><9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com><492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> Message-ID: >>> http://computer-go.org/pipermail/computer-go/2008-October/016680.html >> Interestingly, I did this a while ago. Here's my results: >> >> $ ./Bench 1 100000 >> b: 14840, w: 17143 mercy: 67982 >> elapsed time: 3.42s >> playouts/sec: 29208 >> >> so, nearly 30k/sec random playouts on 9x9. That's using a hack that stops >> the game when the score is heavily in favour of one player, it drops to >> around 20k/sec with that turned off. > > Nice!-) 20k playouts/sec (without the early cutoffs) is the rough number > usually mentioned for these light playouts, reachable even in Java. My own > Haskell code for that was a factor of 5 slower:-( actually, that 5x is relative to jrefbot on my machine (Pentium M760, 2Ghz), which doesn't quite reach 20k/sec, so if your code would run at 20k/sec on my laptop, it would be 10x as fast as my bot:-(( Since you can't release your code, could you perhaps time the jrefbot from the url above on your machine as a reference point, so that I know how far I've yet to go? Something like: $ time ((echo "genmove b";echo "quit") | d:/Java/jre6/bin/java -jar refbots/javabot/jrefgo.jar 20000) = E5 real 0m2.539s user 0m0.030s sys 0m0.031s Btw, I just realised where my bot dropped from 5x to 8x: to work around http://hackage.haskell.org/trac/ghc/ticket/2669 all my array accesses were wrapped in exception handlers, to get useful error messages while I adapted my code to the refbot spec.. That's not the only bug that got in the way: http://hackage.haskell.org/trac/ghc/ticket/2727 forced me to move from functional to imperative arrays much sooner than I wanted, and due to http://hackage.haskell.org/trac/ghc/ticket/1216 I did not even consider 2d arrays (the tuple allocations might have gotten in the way anyhow, but still..). What do those folks working on parallel Haskell arrays think about the sequential Haskell array baseline performance? Claus -- my slow bot's current time (for 20k playouts on a 2Ghz laptop): $ time ((echo "genmove b";echo "quit") | ./SimpleGo.exe 20000) TEXT e5 - amaf-score: 0.127 TEXT e6 - amaf-score: 0.126 TEXT d5 - amaf-score: 0.126 TEXT f5 - amaf-score: 0.118 TEXT d6 - amaf-score: 0.116 TEXT f4 - amaf-score: 0.115 TEXT e7 - amaf-score: 0.115 TEXT f6 - amaf-score: 0.114 TEXT d4 - amaf-score: 0.110 TEXT d3 - amaf-score: 0.108 TEXT e5 - amaf-score: 0.127 = e5 = real 0m10.711s user 0m0.030s sys 0m0.031s From dominic.steinitz at blueyonder.co.uk Thu Nov 27 13:10:53 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Thu Nov 27 13:16:02 2008 Subject: [Haskell-cafe] Building QuickCheck 2 Under GHC 6.10.1 Message-ID: <492EE2AD.8030301@blueyonder.co.uk> Having been a happy user of QuickCheck 2 for many years, I now find it won't build under ghc 6.10.1. Before I investigate further, has anyone encountered this problem and has a fix? Thanks, Dominic. > C:\Users\Dom\QuickCheck>Setup build > Preprocessing library QuickCheck-2.0... > Building QuickCheck-2.0... > [2 of 9] Compiling Test.QuickCheck.Exception ( Test\QuickCheck\Exception.hs, dis > t\build\Test\QuickCheck\Exception.o ) > > Test\QuickCheck\Exception.hs:12:31: > Class `Exception' used as a type > In the type `Exception' > In the type `Either Exception a' > In the type `IO (Either Exception a)' > > Test\QuickCheck\Exception.hs:15:36: > Class `Exception' used as a type > In the type `Exception' > In the type `Either Exception a' > In the type `IO (Either Exception a)' From deduktionstheorem at web.de Thu Nov 27 13:37:28 2008 From: deduktionstheorem at web.de (Stephan Friedrichs) Date: Thu Nov 27 13:31:14 2008 Subject: [Haskell-cafe] followedBy parser in Parsec In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CCB00@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CCB00@EX2.ad.dcs.gla.ac.uk> Message-ID: <492EE8E8.4080403@web.de> Paul Keir wrote: > Is there a way in Parsec to check what the next token is, and if it is > what you're hoping for, leave it there. Maybe you're looking for 'lookAhead'? > > [...] //Stephan -- Fr?her hie? es ja: Ich denke, also bin ich. Heute wei? man: Es geht auch so. - Dieter Nuhr From dons at galois.com Thu Nov 27 13:43:53 2008 From: dons at galois.com (Don Stewart) Date: Thu Nov 27 13:37:32 2008 Subject: [Haskell-cafe] Re: Go Haskell! In-Reply-To: References: <718AAA7EDD8244709E670ACE86B80C29@cr3lt> Message-ID: <20081127184353.GC23682@scytale.galois.com> claus.reinke: > >>>http://computer-go.org/pipermail/computer-go/2008-October/016680.html > >>Interestingly, I did this a while ago. Here's my results: > >> > >>$ ./Bench 1 100000 > >>b: 14840, w: 17143 mercy: 67982 > >>elapsed time: 3.42s > >>playouts/sec: 29208 > >> > >>so, nearly 30k/sec random playouts on 9x9. That's using a hack that > >>stops the game when the score is heavily in favour of one player, it > >>drops to around 20k/sec with that turned off. > > > >Nice!-) 20k playouts/sec (without the early cutoffs) is the rough number > >usually mentioned for these light playouts, reachable even in Java. My own > >Haskell code for that was a factor of 5 slower:-( > > actually, that 5x is relative to jrefbot on my machine (Pentium M760, 2Ghz), > which doesn't quite reach 20k/sec, so if your code would run at 20k/sec on > my laptop, it would be 10x as fast as my bot:-(( Since you can't release > your > code, could you perhaps time the jrefbot from the url above on your machine > as a reference point, so that I know how far I've yet to go? Something like: > > $ time ((echo "genmove b";echo "quit") | > d:/Java/jre6/bin/java -jar refbots/javabot/jrefgo.jar 20000) > = E5 > > real 0m2.539s > user 0m0.030s > sys 0m0.031s > > Btw, I just realised where my bot dropped from 5x to 8x: to work around > > http://hackage.haskell.org/trac/ghc/ticket/2669 > > all my array accesses were wrapped in exception handlers, to get > useful error messages while I adapted my code to the refbot spec.. > > That's not the only bug that got in the way: > > http://hackage.haskell.org/trac/ghc/ticket/2727 > > forced me to move from functional to imperative arrays much sooner > than I wanted, and due to > > http://hackage.haskell.org/trac/ghc/ticket/1216 > > I did not even consider 2d arrays (the tuple allocations might have gotten > in the way anyhow, but still..). > > What do those folks working on parallel Haskell arrays think about the > sequential Haskell array baseline performance? Try using a fast array library like uvector? (With no serious overhead for tuples too, fwiw)... -- Don From dons at galois.com Thu Nov 27 13:45:01 2008 From: dons at galois.com (Don Stewart) Date: Thu Nov 27 13:38:39 2008 Subject: [Haskell-cafe] Building QuickCheck 2 Under GHC 6.10.1 In-Reply-To: <492EE2AD.8030301@blueyonder.co.uk> References: <492EE2AD.8030301@blueyonder.co.uk> Message-ID: <20081127184501.GD23682@scytale.galois.com> Indeed. The base3/base4 simultaneous install. http://haskell.org/haskellwiki/Upgrading_packages#runhaskell Two solutions: cabal install quickcheck (will determine the base dependency correct). or: runhaskell Setup.hs configure --constraint='base<4' dominic.steinitz: > Having been a happy user of QuickCheck 2 for many years, I now find it > won't build under ghc 6.10.1. Before I investigate further, has anyone > encountered this problem and has a fix? > > Thanks, Dominic. > > >C:\Users\Dom\QuickCheck>Setup build > >Preprocessing library QuickCheck-2.0... > >Building QuickCheck-2.0... > >[2 of 9] Compiling Test.QuickCheck.Exception ( > >Test\QuickCheck\Exception.hs, dis > >t\build\Test\QuickCheck\Exception.o ) > > > >Test\QuickCheck\Exception.hs:12:31: > > Class `Exception' used as a type > > In the type `Exception' > > In the type `Either Exception a' > > In the type `IO (Either Exception a)' > > > >Test\QuickCheck\Exception.hs:15:36: > > Class `Exception' used as a type > > In the type `Exception' > > In the type `Either Exception a' > > In the type `IO (Either Exception a)' > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From dons at galois.com Thu Nov 27 16:16:51 2008 From: dons at galois.com (Don Stewart) Date: Thu Nov 27 16:10:27 2008 Subject: [Haskell-cafe] Re: Suggestion: Syntactic sugar for Maps! In-Reply-To: <262872015.20081128000854@gmail.com> References: <262872015.20081128000854@gmail.com> Message-ID: <20081127211651.GL23996@scytale.galois.com> bulat.ziganshin: > Hello circ, > > Thursday, November 27, 2008, 9:59:08 PM, you wrote: > > So why not {"hello": 1, "there": 2} ? > > mymap "hello:1 there:2" > > where mymap implementation is left to the reader :) Hey, well, even easier: {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE FlexibleInstances #-} import Data.Map import Data.String import Text.JSON instance IsString (Map Int Bool) where fromString = fromList . read -- or, say, JSON syntax for assoc lists. {- fromString s = case resultToEither (decode s) of Right a -> a Left s -> error s -} test :: Map Int Bool test = "[(7, True), (1, False)]" main = print test -- Don From claus.reinke at talk21.com Thu Nov 27 16:20:20 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Nov 27 16:14:05 2008 Subject: [Haskell-cafe] Re: Go Haskell! References: <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <20081127184353.GC23682@scytale.galois.com> Message-ID: >> What do those folks working on parallel Haskell arrays think about the >> sequential Haskell array baseline performance? > > Try using a fast array library like uvector? (With no serious overhead for > tuples too, fwiw)... I downloaded uvector a while ago, but haven't got round to trying it (yet another array API?). Mostly, I'd like to know a little more than just "fast array lib": - in which ways is it supposed to be faster? why? - for which usage patterns is it optimised? how? - if it is faster in general, why hasn't it replaced the default arrays? In general, I think Haskell has too many array libraries, with too many APIs. And that doesn't even take account the overuse of unsafe APIs, or the non-integrated type-level safety tricks - if array accesses were properly optimized, there should be a lot less need for the extreme all-or-nothing checks or home-grown alternative special-purpose APIs: - type-level code for watermarking indices belonging to certain index sets is one step to eliminate index checks, but hasn't been integrated into any of the standard libs - one could also associate index subsets with operations that do not leave the index superset belonging to an array (eg, if min 'lookAhead' is exactly what I needed: try $ array_element >>= \ae -> lookAhead (reservedOp "(") >> return ae Many thanks, Paul Maybe you're looking for 'lookAhead'? > > [...] //Stephan -- Fr?her hie? es ja: Ich denke, also bin ich. Heute wei? man: Es geht auch so. - Dieter Nuhr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081127/b0925eb1/attachment.htm From andrewcoppin at btinternet.com Thu Nov 27 16:58:49 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Nov 27 16:52:26 2008 Subject: [Haskell-cafe] Re: Go Haskell! In-Reply-To: References: <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <20081127184353.GC23682@scytale.galois.com> Message-ID: <492F1819.1020104@btinternet.com> Claus Reinke wrote: > In general, I think Haskell has too many array libraries, with too > many APIs. And that doesn't even take account the overuse of > unsafe APIs, or the non-integrated type-level safety tricks - if array > accesses were properly optimized, there should be a lot less need for > the extreme all-or-nothing checks or home-grown > alternative special-purpose APIs: > > - type-level code for watermarking indices belonging to certain > index sets is one step to eliminate index checks, but hasn't been > integrated into any of the standard libs > - one could also associate index subsets with operations that do > not leave the index superset belonging to an array (eg, if > min - GHC does seem to common up index checks only if they are > identical, but if min are really necessary (as long as we know about '+') > - whole-array ops allow to avoid index checks without type-level > tricks, leaving the indexing implicit; but the corresponding ops > in Data.Array.MArray claim to construct new arrays, contrary > to the intended inplace updating for which one uses MArrays? > - etc. etc. > > At least, uvector seems to take multi-element ops more seriously. > But with so many people working on sequential and parallel Haskell > array libraries, I was hoping for someone to take a big ax and clear > out all that sick and half-dead wood, to give a small number of > healthy arrays libs room to grow. Would be a lot easier for us poor naive > Haskell array users who otherwise tend to get lost in that forrest!-) +3 The current array situation is unecessarily messy - and I prefer mathematical elegance to ad-hoc mess. (And you think I use Haskell, why exactly?) Of course, it's all very well complaining about it... somebody still has to *do* all this wonderful stuff. :-/ From dagit at codersbase.com Thu Nov 27 17:24:03 2008 From: dagit at codersbase.com (Jason Dagit) Date: Thu Nov 27 17:17:42 2008 Subject: [Haskell-cafe] Re: Go Haskell! In-Reply-To: References: <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <20081127184353.GC23682@scytale.galois.com> Message-ID: On Thu, Nov 27, 2008 at 1:20 PM, Claus Reinke wrote: > What do those folks working on parallel Haskell arrays think about the >>> sequential Haskell array baseline performance? >>> >> >> Try using a fast array library like uvector? (With no serious overhead for >> tuples too, fwiw)... >> > > I downloaded uvector a while ago, but haven't got round to trying it > (yet another array API?). Mostly, I'd like to know a little more than just > "fast array lib": > > - in which ways is it supposed to be faster? why? > - for which usage patterns is it optimised? how? > - if it is faster in general, why hasn't it replaced the default arrays? > > In general, I think Haskell has too many array libraries, with too > many APIs. And that doesn't even take account the overuse of > unsafe APIs, or the non-integrated type-level safety tricks - if array > accesses were properly optimized, there should be a lot less need for the > extreme all-or-nothing checks or home-grown > alternative special-purpose APIs: > > - type-level code for watermarking indices belonging to certain index > sets is one step to eliminate index checks, but hasn't been > integrated into any of the standard libs > - one could also associate index subsets with operations that do not > leave the index superset belonging to an array (eg, if min min<=i+-1<=max, still safe without checks) > - GHC does seem to common up index checks only if they are > identical, but if min really necessary (as long as we know about '+') > - whole-array ops allow to avoid index checks without type-level > tricks, leaving the indexing implicit; but the corresponding ops > in Data.Array.MArray claim to construct new arrays, contrary > to the intended inplace updating for which one uses MArrays? > - etc. etc. This library would satisfy most of your requirements I suspect: http://ofb.net/~frederik/vectro/draft-r2.pdf My understanding is that the author's code could be turned into a real library fairly easily if it hasn't been already. I only read the paper; I didn't go looking for the library on hackage, but the author does provide the code for the library. The author also says their Haskell code is faster than the same algorithm in Matlab. But, I have to say. Whenever you're faking dependent types in Haskell things get harder to understand for the programmer. Checkout the section in the above paper about type checking. Dependent types, even simulated ones, come with lots of cool static guarantees but understanding how to program with them comes with a high barrier to entry. I think this cognitive load is even higher in Haskell where dependent types have to simulated by doing seemingly bizarre things. I think it is this usability aspect that prevents the techniques from becoming more common in Haskell. > > > At least, uvector seems to take multi-element ops more seriously. > But with so many people working on sequential and parallel Haskell > array libraries, I was hoping for someone to take a big ax and clear > out all that sick and half-dead wood, to give a small number of healthy > arrays libs room to grow. Would be a lot easier for us poor naive > Haskell array users who otherwise tend to get lost in that forrest!-) Sometimes a good library design is an evolutionary process. Maybe it's time to apply a fitness function. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081127/a07eafa7/attachment.htm From toby.hutton at gmail.com Thu Nov 27 18:06:42 2008 From: toby.hutton at gmail.com (Toby Hutton) Date: Thu Nov 27 18:00:22 2008 Subject: [Haskell-cafe] Re: Fun with type functions In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33281447D7F@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33281447D7F@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <711894390811271506j146a23b0tbe2cc686c1652c71@mail.gmail.com> On Thu, Nov 27, 2008 at 8:29 PM, Simon Peyton-Jones wrote: > So this message is to ask you: > > can you tell us about the most persuasive, fun application > you've encountered, for type families or functional dependencies? I only just discovered functional dependencies a week or two ago, and when it solved my problem it absolutely made my day. I was reading 'Bananas, Lenses, etc.' and wanted to implement paramorphic recursion with a type class. My initial attempt: class Paramorphic p where term :: p -> Bool this :: p -> a next ::: p -> p para :: (Paramorphic p) => t -> (a -> (p, t) -> t) ->p -> t para a f p | term p = a | otherwise = f (this p) (next p, para a f (next p)) instance Paramorphic Int where term = (== 0) this = id next = subtract 1 This is broken, since 'a' in 'this' is loose. Then I found multiple class parameters: class Paramorphic p a where ... But 'a' was still too loose--para's type became para :: (Paramorphic p a, Paramorphic p a1, Paramorphic p a2, Paramorphic p a3) => t -> (a1 -> (p, t) -> t) -> p -> t But a fundep solved it for me: class Paramorphic p a | p -> a where ... I could now pretty much do factorial and tails from the paper. fact = para 1 (\a (_, b) -> a * b) instance Paramorphic [a] a where term = null this = head next = tail tails = para [[]] (\a (as, b) -> (a : as) : b) Not exactly a 'fun' example, but I was smiling for hours after discovering this. :) Toby. From jason.dusek at gmail.com Thu Nov 27 19:17:09 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Thu Nov 27 19:10:47 2008 Subject: [Haskell-cafe] Re: Suggestion: Syntactic sugar for Maps! In-Reply-To: <20081127211651.GL23996@scytale.galois.com> References: <262872015.20081128000854@gmail.com> <20081127211651.GL23996@scytale.galois.com> Message-ID: <42784f260811271617p51c98a86uafb2ccaf2b20c509@mail.gmail.com> In all fairness, this basically forces you to say "trust me" to the compiler for something that should be verifiable statically. A typo results in a runtime error -- in a way, this is worse than Perl. Quasi-quotes are really the "right answer" but hardly simple in this case... -- _jsn From ahunter at cs.hmc.edu Thu Nov 27 19:21:21 2008 From: ahunter at cs.hmc.edu (Andrew Hunter) Date: Thu Nov 27 19:15:00 2008 Subject: [Haskell-cafe] Shared modification inside lambdas Message-ID: <20081128002121.GJ8427@knuth.cs.hmc.edu> I'm developing an embedded DSL in Haskell (for exact real arithmetic work, but that's irrelevant right now.) Among other things, the language contains functions and application, as well as various terms. In one iteration, the abstract syntax looked kinda like this (in spirit, don't worry about the actually available terms...) data Expr = Var String | Const Int | Plus Expr Expr | Quantified Range String Expr | Lambda String Expr | App Expr Expr Here, lambda-terms just have the name of their bound variable and the RHS. Quantified terms are much like specialized lambdas; one note is that you *will* have to evaluate the RHS of the quantified term with many values for the argument. It's obvious how to write an evaluator on these--just keep an environment, etc. All well and good, but it seems to me that if I'm embedding the DSl, shouldn't I be able to use the host language's facilities--for example, function abstractions and applications--directly? Well, I tried this, and it seems it works OK, like so: data Expr = Var String | Const Int | Plus Expr Expr | Quantified Range (Int -> Expr) I replaced Lambda terms and applications with Haskell-level functions. Note that my quantifiers still need internal functions, but I replaced them in the same fashion. However, I have a problem; one thing I often have to do with expressions is refine them, where refine has type: refine :: Expr -> Expr and transforms expressions into more interesting ones via certain, mostly simple rules. The problem comes with functions, either just plain lambdas or quantified ones. The rule for refining functions boils down to just refining (recursively) the RHS; in the old version, that was easy! refine (Lambda var rhs) = Lambda var (refine rhs) I only refine while evaluating terms of type Expr, so top level functions aren't important--by the time I'm evaluating them, I've applied them to arguments--but quantified terms are a problem. I could write something like: refine (Quantified range pred) = Quantified range pred' where pred' = \c -> refine (pred c) But the problem is that this refines the term, again, every time I apply an argument to pred': I know I'm going to apply arguments many times to that new pred, and I want to refine it /once/: refinement is argument-agnostic, it only rearranges the structure of the AST, so in theory it'd be nice if I could refine that structure, just duplicating references to the appropriate free variable where I would have duplicated refences to the appropriate (Var String) before. Am I sore out of luck here? Is there a reasonable way I can implement my internal functions via Haskell functions, but apply argument-agnostic transformations to the RHS in a shared fashion? Or, is there some optimization in GHC that means I don't need to worry about this? Thanks, AHH From ryani.spam at gmail.com Thu Nov 27 20:03:55 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Nov 27 19:57:34 2008 Subject: [Haskell-cafe] Fun with type functions In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33281447D7F@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33281447D7F@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <2f9b2d30811271703m7fd57c03v789023fe0722a8dd@mail.gmail.com> My work on lightweight session types (modeled after this year's ICFP paper on the same subject) used type and data families extensively for an elegant way of connecting communicating coroutines: Empty types are used for sessions: > data Eps -- empty session > data a :?: s -- read an "a" followed by session "s" > data a :!: s -- write an "a" followed by session "s" > -- etc. These have kind *, which makes them easy to use in other type-level code; my first formulation had the session types as functors directly, but that led to needing kind signatures elsewhere and made working with these types much more difficult.. Type families are used to represent the dual of a session; that is, a session that reads an Int can connect with a session that writes an Int. > type family Dual s > type instance Dual Eps = Eps > type instance Dual (a :?: s) = a :!: Dual s > type instance Dual (a :!: s) = a :?: Dual s > -- etc. Then data families give structure to the session: > data family Rep s a > newtype instance Rep Eps a = Done a > data instance Rep (x :!: s) a = Send x (Rep s a) > newtype instance Rep (x :?: s) a = Receive (x -> Rep s a) > -- etc. Rep s converts a sessions (kind *) into a functor (kind * -> *). It also allows easy experimentation with alternate formulations of the problem that potentially have different kinds. Finally, a typeclass allows interpretation of these types, connecting two sessions together to run as coroutines: > class Coroutine s where > connect :: (Dual s ~ c, Dual c ~ s) => Rep s a -> Rep c b -> (a,b) > > instance Coroutine Eps where > connect (Done a) (Done b) = (a,b) > instance Coroutine s => Coroutine (x :!: s) where > connect (Send x s) (Receive k) = connect s (k x) > instance Coroutine s => Coroutine (x :?: s) where > connect (Receive k) (Send x c) = connect (k x) c The proof that two routines can safely connect is done entirely at compile time; the connection routine just takes care of routing data between the two processes. -- ryan On Thu, Nov 27, 2008 at 1:29 AM, Simon Peyton-Jones wrote: > Friends > > GHC has embodied data type families since 6.8, and now type synonym families (aka type functions) in 6.10. However, apart from our initial papers there isn't much published material about how to *use* type families. But that hasn't stopped you: quite a few people are using them already, and of course there is a rich seam of work on using functional dependencies to express type-level computation. > > Ken Shan and Oleg Kiselyov and I are collaborating to write a paper for an upcoming workshop, under the general rubric of "Fun with type functions" (in homage to Thomas Hallgren's paper "Fun with functional dependencies" and Ralf Hinze's paper "Fun with phantom types"). > > So this message is to ask you: > > can you tell us about the most persuasive, fun application > you've encountered, for type families or functional dependencies? > > Simple is good. It doesn't have to be elaborate: just something that does something useful you could not have done otherwise. Pointers to email threads are fine. Don't assume we already know about them (even if we participated in the thread :-) Part of what we're interested in is that *you* found the example compelling. > > Many thanks > > Simon, Ken, Oleg > > PS: I'm broadcasting this message to GHC-users and Haskell-cafe, but to avoid deluging ghc-users, please reply just to us and Haskell cafe. (Interested ghc-users can follow the threads there from the archives if they want.) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From rl at cse.unsw.edu.au Thu Nov 27 23:05:58 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Thu Nov 27 22:59:40 2008 Subject: [Haskell-cafe] Need machine for DPH benchmarking In-Reply-To: <37006B2E-B4CF-46F9-9420-61A556B3DF4A@cse.unsw.edu.au> References: <37006B2E-B4CF-46F9-9420-61A556B3DF4A@cse.unsw.edu.au> Message-ID: Hi again, a big thank you to all the people who offered us machines. I think we should be fine now. World domination is just around the corner! Roman On 27/11/2008, at 18:45, Roman Leshchinskiy wrote: > Hi all, > > we, the DPH team, are at the moment in the very unfortunate > situation of not having a proper machine for running our benchmarks > on. Could a kind soul maybe give us (i.e., me) access to a quadcore > or 2xquadcore x86 Linux or OS X machine? I only need to build ghc on > it and run small benchmarks which never take more than a couple of > minutes, maybe once every couple of days or so. We do need to use > all cores, though, so no other CPU-intensive processes can be > running during benchmarking. This is only for a week or two, until > we get our own machine. We would be eternally grateful and won't > forget you when DPH takes over the world. > > Roman > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From chak at cse.unsw.edu.au Fri Nov 28 00:09:20 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Fri Nov 28 00:03:11 2008 Subject: [Haskell-cafe] Re: Go Haskell! In-Reply-To: References: <1226399902.6496.9.camel@rubix.office.last.fm><9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com><492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> Message-ID: <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> Claus Reinke: > What do those folks working on parallel Haskell arrays think about the > sequential Haskell array baseline performance? You won't like the answer. We are not happy with the existing array infrastructure and hence have our own. Roman recently extracted some of it as a standalone package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vector In the longer run, we would like to factor our library into DPH- specific code and general-purpose array library that you can use independent of DPH. Manuel From vigalchin at gmail.com Fri Nov 28 00:56:04 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri Nov 28 00:49:42 2008 Subject: [Haskell-cafe] I have forgotten .. ghci question Message-ID: <5ae4f2ba0811272156s60a4dcccm2f7a30851da26cb2@mail.gmail.com> Hello, I have an experimental version of a package ~/FTP/Haskell/blah. Who I "point" ghci ath this experimental package version so I can poke around? Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081127/cf85729d/attachment.htm From voigt at tcs.inf.tu-dresden.de Fri Nov 28 02:00:17 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Fri Nov 28 01:53:56 2008 Subject: [Haskell-cafe] ANNOUNCE: Haskell Communities and Activities Report (15th ed., November 2008) Message-ID: <492F9701.9010707@tcs.inf.tu-dresden.de> On behalf of the many, many contributors, I am pleased to announce that the Haskell Communities and Activities Report (15th edition, November 2008) http://www.haskell.org/communities/ is now available from the Haskell Communities home page in PDF and HTML formats. Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as I did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline ;-) to the call. The editor collects all the contributions into a single report and feeds that back to the community. When I try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: ---------------------------------------- End of April 2009: target deadline for contributions to the May 2009 edition of the HC&A Report ---------------------------------------- Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to "register" with the editor for a simple e-mail reminder in April (you could point me to them as well, and I can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Janis Voigtlaender -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From jules at jellybean.co.uk Fri Nov 28 02:04:01 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Fri Nov 28 01:57:42 2008 Subject: [Haskell-cafe] Re: Suggestion: Syntactic sugar for Maps! In-Reply-To: <20081127211651.GL23996@scytale.galois.com> References: <262872015.20081128000854@gmail.com> <20081127211651.GL23996@scytale.galois.com> Message-ID: <492F97E1.1000908@jellybean.co.uk> Don Stewart wrote: > bulat.ziganshin: >> Hello circ, >> >> Thursday, November 27, 2008, 9:59:08 PM, you wrote: >>> So why not {"hello": 1, "there": 2} ? >> mymap "hello:1 there:2" >> >> where mymap implementation is left to the reader :) I can't see the context of the beginning of this thread, but I've always found: fromList [("hello",1),("there",2)] to be a relatively simple syntax, and still checked at compile time. Anonymous sum + product types plus lists are a pretty good approximation for lots of concrete syntax, and they're type checks. (Anonymous sum, Either, is slightly more syntactically heavy than you'd like, though...) Jules From lrpalmer at gmail.com Fri Nov 28 02:06:56 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Fri Nov 28 02:00:34 2008 Subject: [Haskell-cafe] Re: Suggestion: Syntactic sugar for Maps! In-Reply-To: <492F97E1.1000908@jellybean.co.uk> References: <262872015.20081128000854@gmail.com> <20081127211651.GL23996@scytale.galois.com> <492F97E1.1000908@jellybean.co.uk> Message-ID: <7ca3f0160811272306x16c3e74ene2ce3f2874ab2713@mail.gmail.com> On Fri, Nov 28, 2008 at 12:04 AM, Jules Bean wrote: > I can't see the context of the beginning of this thread, but I've always > found: > > fromList [("hello",1),("there",2)] > > to be a relatively simple syntax, and still checked at compile time. I never liked that. Too much syntax overhead. But this clears it right up: foo = fromList [ "hello" >: 1, "there" >: 2 ] where (:>) = (,) And also I haven't been following the thread, so this may not be any kind of answer. Luke From marlowsd at gmail.com Fri Nov 28 04:04:27 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 28 03:58:10 2008 Subject: [Haskell-cafe] Re: Go Haskell! In-Reply-To: <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> References: <1226399902.6496.9.camel@rubix.office.last.fm><9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com><492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> Message-ID: <492FB41B.6000700@gmail.com> Manuel M T Chakravarty wrote: > Claus Reinke: >> What do those folks working on parallel Haskell arrays think about the >> sequential Haskell array baseline performance? > > You won't like the answer. We are not happy with the existing array > infrastructure and hence have our own. Roman recently extracted some of > it as a standalone package: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vector > > In the longer run, we would like to factor our library into DPH-specific > code and general-purpose array library that you can use independent of DPH. So we have two vector libraries, vector and uvector, which have a lot in common - they are both single-dimension array types that support unboxed instances and have list-like operations with fusion. They ought to be unified, really. The main difference between these libraries and Haskell's arrays is the Ix class. So perhaps Haskell's arrays should be reimplemented on top of the low-level vector libraries? The Ix class is the root cause of the problems with optimising the standard array libraries. Cheers, Simon From johan.tibell at gmail.com Fri Nov 28 07:29:10 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri Nov 28 07:22:48 2008 Subject: [Haskell-cafe] Re: Go Haskell! In-Reply-To: <492FB41B.6000700@gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com> <492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> <492FB41B.6000700@gmail.com> Message-ID: <90889fe70811280429r1666fbc7n1ba077a61853b2fe@mail.gmail.com> On Fri, Nov 28, 2008 at 10:04 AM, Simon Marlow wrote: > Manuel M T Chakravarty wrote: >> In the longer run, we would like to factor our library into DPH-specific >> code and general-purpose array library that you can use independent of DPH. > > So we have two vector libraries, vector and uvector, which have a lot in > common - they are both single-dimension array types that support unboxed > instances and have list-like operations with fusion. They ought to be > unified, really. Yes please! Could we please have a ByteString style interface with qualified imports instead of using ad-hoc name prefixes/suffixes as a namespacing mechanism if we're going to merge the two libraries? Cheers, Johan From briqueabraque at yahoo.com Fri Nov 28 08:49:06 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Fri Nov 28 08:43:02 2008 Subject: [Haskell-cafe] Question about fastcgi Message-ID: Hi, I'm learnng to use fastcgi and, reading the examples, I see the main "loop" is like this: main = runFastCGI my_work However, isn't a fastcgi program supposed to choose a port where to listen to calls? For instance, in this C example: xzdev.com/nginx_fastcgi.html doesn't the line listen_socket = FCGX_OpenSocket(":8002", 2000); says it's listening to port 8002? I read the code for fastcgi, from hackage, and I can't find anything related to ports like, for instance, a default port. Am I understanding something the wrong way? Thanks, Maur?cio From duncan.coutts at worc.ox.ac.uk Fri Nov 28 08:56:26 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 28 08:50:09 2008 Subject: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs In-Reply-To: <20081127172008.GA20810@matrix.chaos.earth.li> References: <20081126143832.GC15463@brighton.ac.uk> <1227738501.19577.42.camel@localhost> <20081127172008.GA20810@matrix.chaos.earth.li> Message-ID: <1227880586.10115.17.camel@localhost> On Thu, 2008-11-27 at 17:20 +0000, Ian Lynagh wrote: > On Wed, Nov 26, 2008 at 10:28:21PM +0000, Duncan Coutts wrote: > > I should note that one moral of this story is to check that your FFI > > imports are correct. That is, check they import the foreign functions at > > the right Haskell types. In this case the mistake was that the foreign > > function returned a C int, but the Haskell foreign import declaration > > stated that the C function returned IO () rather than IO CInt. > > While that's true, Haskell also makes it easy to make the same sort of > error with IO (or any other Monad) values, whether created with the FFI > or not. If you say > > f = do x > y > z > and y has type IO CInt then you won't get an error (and I don't think > you can even ask for a warning with the current implementations). Right, which is why we do not use IO CInt style error handling much in Haskell. For functions that return a real result we use Maybe, or for things that would otherwise be IO (), then using IO exceptions is the obvious thing to do. In either case the error is hard to ignore. Duncan From duncan.coutts at worc.ox.ac.uk Fri Nov 28 09:08:31 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 28 09:02:11 2008 Subject: [Haskell-cafe] Re: catting to cat gets stuck at > 135K In-Reply-To: <00034B2E-5008-4489-855C-D5AD524509FB@ece.cmu.edu> References: <42784f260811101329o6fde82f5x1a9636e4cd8ba948@mail.gmail.com> <5558E5DB-A741-4FF9-8596-FC70BC9BF835@ece.cmu.edu> <42784f260811101604q595bfaeam1c07d1a918fca7cd@mail.gmail.com> <492EA5C9.7050803@gmail.com> <00034B2E-5008-4489-855C-D5AD524509FB@ece.cmu.edu> Message-ID: <1227881311.10115.21.camel@localhost> On Thu, 2008-11-27 at 11:38 -0500, Brandon S. Allbery KF8NH wrote: > On 2008 Nov 27, at 8:51, Simon Marlow wrote: > > No, the issue is that without real OS threads, a foreign call can't > > be pre-empted (pretty obvious when you think about it). > > waitForProcess ends up making a blocking foreign call - non-obvious, > > but at least it's documented. > > The way this is usually handled in the non-threaded case is to either > use SIGCHLD or non-blocking waitpid() so that "green" threads can > continue running. I'm a little surprised this wasn't done. Yes, we've discussed this in detail a few months back. We even have a partial implementation. However it stalled on needing a better signals API which we have not managed to get through the standardisation process. Unfortunately there is no non-blocking (non-polling) waitpid() and the global (process-scope) nature of signals is a pain. Duncan From haskell at list.mightyreason.com Fri Nov 28 10:07:30 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Fri Nov 28 10:01:21 2008 Subject: [Haskell-cafe] Re: Question about fastcgi In-Reply-To: References: Message-ID: <49300932.1080601@list.mightyreason.com> Er, no. A fastcgi executable is (like a cgi executable) controlled by the front end web server. I run my fastcgi using Apache as the front end. The front end web server will control things like the port number. Mauricio wrote: > Hi, > > I'm learnng to use fastcgi and, reading the examples, > I see the main "loop" is like this: > > main = runFastCGI my_work > > However, isn't a fastcgi program supposed to choose > a port where to listen to calls? For instance, in this > C example: > > xzdev.com/nginx_fastcgi.html > > doesn't the line > > listen_socket = FCGX_OpenSocket(":8002", 2000); > > says it's listening to port 8002? I read the code > for fastcgi, from hackage, and I can't find anything > related to ports like, for instance, a default port. > Am I understanding something the wrong way? > > Thanks, > Maur?cio From colin at colina.demon.co.uk Fri Nov 28 10:15:46 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Fri Nov 28 10:09:25 2008 Subject: [Haskell-cafe] Re: Question about fastcgi In-Reply-To: <49300932.1080601@list.mightyreason.com> (ChrisK's message of "Fri\, 28 Nov 2008 15\:07\:30 +0000") References: <49300932.1080601@list.mightyreason.com> Message-ID: >>>>> "ChrisK" == ChrisK writes: ChrisK> Er, no. A fastcgi executable is (like a cgi executable) ChrisK> controlled by the front end web server. I run my fastcgi ChrisK> using Apache as the front end. The front end web server ChrisK> will control things like the port number. There are different ways to run a FasctCGI executable (three if my memory serves me correctly). I have only ever written FasctCGI executables (not in Haskell) when the server accepts a port number at start up, and is started independently of Apache (or whatever). And Apache is told which port numbers it will find the servers on. ChrisK> Mauricio wrote: >> Hi, >> >> I'm learnng to use fastcgi and, reading the examples, I see the >> main "loop" is like this: >> >> main = runFastCGI my_work >> >> However, isn't a fastcgi program supposed to choose a port >> where to listen to calls? For instance, in this C example: >> >> xzdev.com/nginx_fastcgi.html >> >> doesn't the line >> >> listen_socket = FCGX_OpenSocket(":8002", 2000); >> >> says it's listening to port 8002? I read the code for fastcgi, >> from hackage, and I can't find anything related to ports like, >> for instance, a default port. Am I understanding something the >> wrong way? >> >> Thanks, Maur?cio -- Colin Adams Preston Lancashire From haskell at list.mightyreason.com Fri Nov 28 10:25:53 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Fri Nov 28 10:19:38 2008 Subject: [Haskell-cafe] Re: Question about fastcgi In-Reply-To: References: <49300932.1080601@list.mightyreason.com> Message-ID: I have only used this, all of these are from Haskell: > pamac-cek10:~ chrisk$ cat /etc/apache2/other/httpd-fastcgi.conf > > Alias /fcgi-bin/ "/Library/WebServer/FastCGI-Executables/" > > > AllowOverride None > Options None > Order allow,deny > Allow from all > > SetHandler fastcgi-script > Options +ExecCGI > > > FastCgiIpcDir "/tmp/fastcgi" > FastCgiServer "/Library/WebServer/FastCGI-Executables/hw.fastcgi" -pass-header Cookie > FastCgiServer "/Library/WebServer/FastCGI-Executables/test.fastcgi" -pass-header Cookie > FastCgiServer "/Library/WebServer/FastCGI-Executables/xwords.fastcgi" -pass-header Cookie > The above is included from the main httpd.conf which has: > pamac-cek10:~ chrisk$ grep -i fast /etc/apache2/httpd.conf > LoadModule fastcgi_module libexec/apache2/mod_fastcgi.so From lemming at henning-thielemann.de Fri Nov 28 10:29:12 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Nov 28 10:22:49 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <492FB41B.6000700@gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com> <492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> <492FB41B.6000700@gmail.com> Message-ID: On Fri, 28 Nov 2008, Simon Marlow wrote: > Manuel M T Chakravarty wrote: >> Claus Reinke: >>> What do those folks working on parallel Haskell arrays think about the >>> sequential Haskell array baseline performance? >> >> You won't like the answer. We are not happy with the existing array >> infrastructure and hence have our own. Roman recently extracted some of it >> as a standalone package: >> >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vector >> >> In the longer run, we would like to factor our library into DPH-specific >> code and general-purpose array library that you can use independent of DPH. > > So we have two vector libraries, vector and uvector, which have a lot in > common - they are both single-dimension array types that support unboxed > instances and have list-like operations with fusion. They ought to be > unified, really. It's worse: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/storablevector :-) From lemming at henning-thielemann.de Fri Nov 28 10:30:43 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Nov 28 10:24:19 2008 Subject: [Haskell-cafe] Re: Go Haskell! In-Reply-To: <90889fe70811280429r1666fbc7n1ba077a61853b2fe@mail.gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com> <492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> <492FB41B.6000700@gmail.com> <90889fe70811280429r1666fbc7n1ba077a61853b2fe@mail.gmail.com> Message-ID: On Fri, 28 Nov 2008, Johan Tibell wrote: > On Fri, Nov 28, 2008 at 10:04 AM, Simon Marlow wrote: > >> So we have two vector libraries, vector and uvector, which have a lot in >> common - they are both single-dimension array types that support unboxed >> instances and have list-like operations with fusion. They ought to be >> unified, really. > > Yes please! Could we please have a ByteString style interface with > qualified imports instead of using ad-hoc name prefixes/suffixes as a > namespacing mechanism if we're going to merge the two libraries? StorableVector is organized this way. From ccshan at post.harvard.edu Fri Nov 28 10:43:24 2008 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Fri Nov 28 10:37:53 2008 Subject: [Haskell-cafe] Re: Shared modification inside lambdas References: <20081128002121.GJ8427@knuth.cs.hmc.edu> Message-ID: Andrew Hunter wrote in article <20081128002121.GJ8427@knuth.cs.hmc.edu> in gmane.comp.lang.haskell.cafe: > All well and good, but it seems to me that if I'm > embedding the DSl, shouldn't I be able to use the host language's > facilities--for example, function abstractions and > applications--directly? Indeed. Using binding in the host language to represent binding in the embedded language is called higher-order abstract syntax (HOAS). > Well, I tried this, and it seems it works OK, like so: > > data Expr = Var String > | Const Int > | Plus Expr Expr > | Quantified Range (Int -> Expr) (Do you still need or even want "Var String"?) > ... I could write something like: > > refine (Quantified range pred) = Quantified range pred' > where > pred' = \c -> refine (pred c) > > But the problem is that this refines the term, again, every time I > apply an argument to pred' ... The paper by Jacques Carette, Oleg Kiselyov, and me http://www.cs.rutgers.edu/~ccshan/tagless/jfp.pdf (revised version to appear in JFP) shows how to perform partial evaluation (which is an optimization, like your refinement) using HOAS. However, it's a bit tricky, in a language like Haskell (98) without so-called metaprogramming or staging facilities at the term level, to make the optimizations happen only once (rather than every time the embedded abstraction is invoked). It can be done! Let me point you to some code that we only mention in passing in that paper, which performs type-checking using HOAS. The type-checking happens only once; then the type-checked term can be interpreted many times. http://okmij.org/ftp/tagless-final/ http://okmij.org/ftp/tagless-final/IncopeTypecheck.hs Hope this helps. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig 2008-11-25 Elimination of Violence Against Women http://unifem.org/vaw/ 1948-12-10 Universal Declaration of Human Rights http://everyhumanhasrights.org From dominic.steinitz at blueyonder.co.uk Fri Nov 28 11:42:27 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Fri Nov 28 11:47:33 2008 Subject: pbkdf2 on hackage Re: Re[2]: [Haskell-cafe] Password hashing In-Reply-To: <910ddf450811270532n891cdfdw81effaebc1c5e87@mail.gmail.com> References: <910ddf450811270532n891cdfdw81effaebc1c5e87@mail.gmail.com> Message-ID: <49301F73.6090201@blueyonder.co.uk> Thomas Hartman wrote: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/PBKDF2 > > Since no one took up my code review request I just did the best I > could and uploaded to hackage. There were indeed some mistakes in my > initial post, fixed now. (Code review is still wished, though!) > > Alas, documentation doesn't build with hackage, altough it does for me > locally. (Seems like almost everything I do these days -- what am I > doing wrong?!) > > Also I'm open to folding this into a more established crypto package > if there are any takers... psst, dominic. I'd be happy to do so. In fact, I have another contribution which I need to work on so maybe now is a good time to roll my sleeves up. I haven't been following the thread on this. Could you give me some references? I assume it's a perfectly good cryptographic function, then it would be very helpful for me if you created a patch against the crypto repository. > > Also, dominic, shouldn't your crypto package be added to category > Cryptography (a cabal file change) so it lists aside the other crypto > packages? Yes good point - something else that needs doing. I've created the first ticket in the trac http://trac.haskell.org/crypto/ticket/1 >>> If there are any crypto gurus who can code-review this I would be much >>> obliged, and when I'm confident enough that this does the right thing >>> I'll put it up on hackage. >>> >>> I don't do much crypto so this *definitely* needs a review before it >>> becomes a library? It depends what you are going to use it for. I've put a big disclaimer on the crypto library because there are all sorts of attacks I've not checked it's proof against (e.g. who knows how long keys are kept in memory by a runtime system). You'd probably have to put in quite a lot of work researching how e.g. this is done in other implementations and seeing how the equivalent protection could be implemented in Haskell. >>> >>> 2008/11/26 John Meacham : >>>> What you are using there is not a salt, but rather a secret key. The >>>> important thing about a salt is that it is different for _every user_. >>>> and you actually store the salt unhashed along with the hash. (it is not >>>> secret information). A salt protects against a dictionary attack, for >>>> instance, you might have a dictionary of hash's and the common passwords >>>> they go to but if you add a 32 bit salt, you would need 2^32 entries for >>>> each dictionary word, making such an attack unworkable. You can also >>>> trivially tell if two users have the _same_ password just by comparing >>>> the hashes without a salt. >>>> John is right but it still doesn't stop you publishing your function which someone can then use as John describes. From donn at avvanta.com Fri Nov 28 13:22:13 2008 From: donn at avvanta.com (Donn Cave) Date: Fri Nov 28 13:16:46 2008 Subject: [Haskell-cafe] Re: catting to cat gets stuck at > 135K References: <42784f260811101329o6fde82f5x1a9636e4cd8ba948@mail.gmail.com> <5558E5DB-A741-4FF9-8596-FC70BC9BF835@ece.cmu.edu> <42784f260811101604q595bfaeam1c07d1a918fca7cd@mail.gmail.com> <492EA5C9.7050803@gmail.com> <00034B2E-5008-4489-855C-D5AD524509FB@ece.cmu.edu> <1227881311.10115.21.camel@localhost> Message-ID: <20081128182213.14275276C41@mail.avvanta.com> Quoth Duncan Coutts : | On Thu, 2008-11-27 at 11:38 -0500, Brandon S. Allbery KF8NH wrote: | |> The way this is usually handled in the non-threaded case is to either |> use SIGCHLD or non-blocking waitpid() so that "green" threads can |> continue running. I'm a little surprised this wasn't done. | | Yes, we've discussed this in detail a few months back. We even have a | partial implementation. However it stalled on needing a better signals | API which we have not managed to get through the standardisation | process. | | Unfortunately there is no non-blocking (non-polling) waitpid() and the | global (process-scope) nature of signals is a pain. SIGCHLD can be a pain in its own unusual way. Once you have a SIGCHLD handler, process exits will interrupt "long" I/O, so every such read(), recv() or whatever must now check for EINTR and restart. Even though the authors of GHC go to great lengths to convert all I/O to non-blocking anyway, this will still apply to external library functions that are beyond GHC's reach. So it's a strategy I would use only if I were kind of desperate. Donn From briqueabraque at yahoo.com Fri Nov 28 14:16:40 2008 From: briqueabraque at yahoo.com (Mauricio) Date: Fri Nov 28 14:10:26 2008 Subject: [Haskell-cafe] Re: Question about fastcgi In-Reply-To: References: <49300932.1080601@list.mightyreason.com> Message-ID: I was able to get this working with lighttpd, and I did had to choose a port, but only at lighttpd configuration, not at the Haskell source. Thanks, Maur?cio ChrisK a ?crit : > I have only used this, all of these are from Haskell: > >> pamac-cek10:~ chrisk$ cat /etc/apache2/other/httpd-fastcgi.conf >> >> Alias /fcgi-bin/ "/Library/WebServer/FastCGI-Executables/" >> >> >> AllowOverride None >> Options None >> Order allow,deny >> Allow from all >> >> SetHandler fastcgi-script >> Options +ExecCGI >> >> >> FastCgiIpcDir "/tmp/fastcgi" >> FastCgiServer "/Library/WebServer/FastCGI-Executables/hw.fastcgi" >> -pass-header Cookie >> FastCgiServer "/Library/WebServer/FastCGI-Executables/test.fastcgi" >> -pass-header Cookie >> FastCgiServer >> "/Library/WebServer/FastCGI-Executables/xwords.fastcgi" -pass-header >> Cookie >> > > The above is included from the main httpd.conf which has: > >> pamac-cek10:~ chrisk$ grep -i fast /etc/apache2/httpd.conf LoadModule >> fastcgi_module libexec/apache2/mod_fastcgi.so From andrewcoppin at btinternet.com Fri Nov 28 16:43:26 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri Nov 28 16:36:59 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: References: <1226399902.6496.9.camel@rubix.office.last.fm> <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com> <492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> <492FB41B.6000700@gmail.com> Message-ID: <493065FE.2090003@btinternet.com> Henning Thielemann wrote: > > On Fri, 28 Nov 2008, Simon Marlow wrote: > >> Manuel M T Chakravarty wrote: >>> Claus Reinke: >>>> What do those folks working on parallel Haskell arrays think about the >>>> sequential Haskell array baseline performance? >>> >>> You won't like the answer. We are not happy with the existing array >>> infrastructure and hence have our own. Roman recently extracted >>> some of it as a standalone package: >>> >>> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vector >>> >>> In the longer run, we would like to factor our library into >>> DPH-specific code and general-purpose array library that you can use >>> independent of DPH. >> >> So we have two vector libraries, vector and uvector, which have a lot >> in common - they are both single-dimension array types that support >> unboxed instances and have list-like operations with fusion. They >> ought to be unified, really. > > It's worse: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/storablevector > :-) What *I* propose is that somebody [you see what I did there?] should sit down, take stock of all the multitudes of array libraries, what features they have, what obvious features they're missing, and think up a good API from scratch. Once we figure out what the best way to arrange all this stuff is, *then* we attack the problem of implementing it for real. It seems lots of people have written really useful code, but we need to take a step back and look at the big picture here before writing any more of it. IMHO, anyway... From dons at galois.com Fri Nov 28 16:46:11 2008 From: dons at galois.com (Don Stewart) Date: Fri Nov 28 16:39:46 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <493065FE.2090003@btinternet.com> References: <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com> <492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> <492FB41B.6000700@gmail.com> <493065FE.2090003@btinternet.com> Message-ID: <20081128214611.GD27887@scytale.galois.com> andrewcoppin: > What *I* propose is that somebody [you see what I did there?] should sit > down, take stock of all the multitudes of array libraries, what features > they have, what obvious features they're missing, and think up a good > API from scratch. Once we figure out what the best way to arrange all > this stuff is, *then* we attack the problem of implementing it for real. > > It seems lots of people have written really useful code, but we need to > take a step back and look at the big picture here before writing any > more of it. No. My view would be to let the free market of developers decide what is best. No bottlenecks -- there's too many Haskell libraries already (~1000 now). And this approach has yielded more code than ever before, more libraries than ever before, and library authors are competing. So let the market decide. We're a bazaar, not a cathedral. -- Don From lennart at augustsson.net Fri Nov 28 17:20:25 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Fri Nov 28 17:14:01 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <20081128214611.GD27887@scytale.galois.com> References: <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> <492FB41B.6000700@gmail.com> <493065FE.2090003@btinternet.com> <20081128214611.GD27887@scytale.galois.com> Message-ID: But I don't want Perl, I want a well designed language and well designed libraries. I think it's find to let libraries proliferate, but at some point you also need to step back and abstract. -- Lennart On Fri, Nov 28, 2008 at 9:46 PM, Don Stewart wrote: > andrewcoppin: >> What *I* propose is that somebody [you see what I did there?] should sit >> down, take stock of all the multitudes of array libraries, what features >> they have, what obvious features they're missing, and think up a good >> API from scratch. Once we figure out what the best way to arrange all >> this stuff is, *then* we attack the problem of implementing it for real. >> >> It seems lots of people have written really useful code, but we need to >> take a step back and look at the big picture here before writing any >> more of it. > > No. > > My view would be to let the free market of developers decide what is > best. No bottlenecks -- there's too many Haskell libraries already (~1000 now). > > And this approach has yielded more code than ever before, more libraries > than ever before, and library authors are competing. > > So let the market decide. We're a bazaar, not a cathedral. > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From prb at mult.ifario.us Fri Nov 28 17:37:14 2008 From: prb at mult.ifario.us (Paul Brown) Date: Fri Nov 28 17:30:52 2008 Subject: [Haskell-cafe] definitive list of editline bindings anywhere? Message-ID: <1248280D-26EC-4F78-8960-6731011820C0@mult.ifario.us> All -- Anyone have a definitive list of editline keybindings available? I find myself missing some of the capabilities of readline, and there doesn't seem to be documentation. -- Paul From judah.jacobson at gmail.com Fri Nov 28 18:02:14 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Nov 28 17:55:50 2008 Subject: [Haskell-cafe] definitive list of editline bindings anywhere? In-Reply-To: <1248280D-26EC-4F78-8960-6731011820C0@mult.ifario.us> References: <1248280D-26EC-4F78-8960-6731011820C0@mult.ifario.us> Message-ID: <6d74b0d20811281502n6800610cpc9810e95ebb5b1ab@mail.gmail.com> On Fri, Nov 28, 2008 at 2:37 PM, Paul Brown wrote: > > All -- > > Anyone have a definitive list of editline keybindings available? I find > myself missing some of the capabilities of readline, and there doesn't seem > to be documentation. You can usually get this from "man editrc", or otherwise the following page: http://www.manpagez.com/man/5/editrc/ -Judah From roly.perera at dynamicaspects.org Fri Nov 28 18:27:22 2008 From: roly.perera at dynamicaspects.org (Roly Perera) Date: Fri Nov 28 18:21:08 2008 Subject: [Haskell-cafe] Using Parsec with other monads Message-ID: Hi, I've spent some time writing a parser using the Parsec library and was looking forward to being able to plug in some side-behaviour once I'd got the parser working. Now it seems I can't actually do that in a nice way because Parsec appears to be "fixed" to a simple State monad. I found this mentioned in the Cafe archives, but not much discussion. Is there a reason Parsec wasn't implemented using the monad transformer approach? Are there any plans to open it up? It's a nice powerful library and a natural thing to want to do for example would be to plug in something like a Reader to track a variable context. I guess one could abuse the State monad to achieve the goal but that feels like the wrong tool for the job. Any insights appreciated. thanks, Roly From derek.a.elkins at gmail.com Fri Nov 28 18:36:01 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Fri Nov 28 18:29:42 2008 Subject: [Haskell-cafe] Using Parsec with other monads In-Reply-To: References: Message-ID: <1227915361.15731.37.camel@derek-laptop> On Fri, 2008-11-28 at 23:27 +0000, Roly Perera wrote: > Hi, > > I've spent some time writing a parser using the Parsec library and was looking > forward to being able to plug in some side-behaviour once I'd got the parser > working. > > Now it seems I can't actually do that in a nice way because Parsec appears to > be "fixed" to a simple State monad. > > I found this mentioned in the Cafe archives, but not much discussion. Is there > a reason Parsec wasn't implemented using the monad transformer approach? Are > there any plans to open it up? It's a nice powerful library and a natural > thing to want to do for example would be to plug in something like a Reader to > track a variable context. I guess one could abuse the State monad to achieve > the goal but that feels like the wrong tool for the job. > > Any insights appreciated. Parsec3 is implemented as a monad transformer. From bulat.ziganshin at gmail.com Fri Nov 28 18:37:56 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Nov 28 18:31:56 2008 Subject: [Haskell-cafe] Using Parsec with other monads In-Reply-To: References: Message-ID: <1432902676.20081129023756@gmail.com> Hello Roly, Saturday, November 29, 2008, 2:27:22 AM, you wrote: > Now it seems I can't actually do that in a nice way because Parsec appears to > be "fixed" to a simple State monad. afaik, version 3 is implemented as monad transformer -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From rl at cse.unsw.edu.au Fri Nov 28 18:45:57 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Fri Nov 28 18:39:47 2008 Subject: [Haskell-cafe] Re: Go Haskell! In-Reply-To: <492FB41B.6000700@gmail.com> References: <1226399902.6496.9.camel@rubix.office.last.fm><9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com><492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> <492FB41B.6000700@gmail.com> Message-ID: On 28/11/2008, at 20:04, Simon Marlow wrote: > So we have two vector libraries, vector and uvector, which have a > lot in common - they are both single-dimension array types that > support unboxed instances and have list-like operations with > fusion. They ought to be unified, really. Yes. This shouldn't be too hard to do since both libraries are based on the internal DPH arrays. Although I have to admit that I never really looked at Don's code and have no idea how much he has changed. But it's more than that. The basic idea behind vector is to provide a common framework for "normal" arrays, ByteString, StorableVector etc. It's not finished by a long shot but (unsurprisingly) I think it goes in the right direction. The proliferation of array-like libraries is counterproductive. > The main difference between these libraries and Haskell's arrays is > the Ix class. So perhaps Haskell's arrays should be reimplemented > on top of the low-level vector libraries? > The Ix class is the root cause of the problems with optimising the > standard array libraries. Yes, Haskell arrays should be based on a lower-level array library. I would also argue that they should be redesigned and given a more streamlined and efficient interface. The Ix class is not the only problem wrt efficiency. In particular, the H98 array library relies quite heavily on lists which makes implementing any kind of array fusion rather hard. In contrast to Ix, this is completely unnecessary, IMO. Roman From claus.reinke at talk21.com Fri Nov 28 18:47:02 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Nov 28 18:40:44 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries References: <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <492EAC58.5080207@gmail.com><718AAA7EDD8244709E670ACE86B80C29@cr3lt><7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au><492FB41B.6000700@gmail.com><493065FE.2090003@btinternet.com><20081128214611.GD27887@scytale.galois.com> Message-ID: <3CFC2F81637043999463748C4C8A0B88@cr3lt> > But I don't want Perl, I want a well designed language and well > designed libraries. > I think it's find to let libraries proliferate, but at some point you > also need to step back and abstract. > > -- Lennart Especially so if the free marketeers claim there is something fundamentally wrong with the standard libraries and language, as in the case of arrays. When someone did that nice little survey of the last bunch of array libraries (Bulat, I think? now in the wiki book), I was hoping there would be a grand unification soon. Instead, it seems that those who have worked most with Haskell arrays recently have simply abandoned all of the standard array libraries. Okay, why not, if there are good reasons. But can't you document those reasons, for each of your alternative proposals, so that people have some basis on which to choose (other than who has the loudest market voice;-)? And would it be difficult for you all to agree on a standard API, to make switching between the alternatives easy (if it is indeed impossible to unify their advantages in a single library, the reasons for which should also be documented somewhere)? And what is wrong about Simon's suggestion, to use the standard array lib APIs on top of your implementations? Not that I see Haskell' coming soon, but I'd certainly not want it to continue standardising a kind of array that appears to have no backing among the Haskell array user/library author community. Nor would I like something as central as arrays to remain outside the standard, where it won't remain stable enough for Haskell programmers to rely on in the long run. bazaar, yes; mayhem, no. Claus > On Fri, Nov 28, 2008 at 9:46 PM, Don Stewart wrote: >> andrewcoppin: >>> What *I* propose is that somebody [you see what I did there?] should sit >>> down, take stock of all the multitudes of array libraries, what features >>> they have, what obvious features they're missing, and think up a good >>> API from scratch. Once we figure out what the best way to arrange all >>> this stuff is, *then* we attack the problem of implementing it for real. >>> >>> It seems lots of people have written really useful code, but we need to >>> take a step back and look at the big picture here before writing any >>> more of it. >> >> No. >> >> My view would be to let the free market of developers decide what is >> best. No bottlenecks -- there's too many Haskell libraries already (~1000 now). >> >> And this approach has yielded more code than ever before, more libraries >> than ever before, and library authors are competing. >> >> So let the market decide. We're a bazaar, not a cathedral. >> >> -- Don >> _______________________________________________ >> 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 rl at cse.unsw.edu.au Fri Nov 28 18:49:13 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Fri Nov 28 18:43:02 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <493065FE.2090003@btinternet.com> References: <1226399902.6496.9.camel@rubix.office.last.fm> <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <20081111215110.GQ28091@scytale.galois.com> <492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> <492FB41B.6000700@gmail.com> <493065FE.2090003@btinternet.com> Message-ID: On 29/11/2008, at 08:43, Andrew Coppin wrote: > What *I* propose is that somebody [you see what I did there?] should > sit down, take stock of all the multitudes of array libraries, what > features they have, what obvious features they're missing, and think > up a good API from scratch. Once we figure out what the best way to > arrange all this stuff is, *then* we attack the problem of > implementing it for real. That is the idea behind vector. I don't know how good it is but it's the best I could come up with (or will be once it's finished). That said, I don't think there is such a thing as a perfect "array API". Different libraries serve different purposes. Roman From dons at galois.com Fri Nov 28 18:57:25 2008 From: dons at galois.com (Don Stewart) Date: Fri Nov 28 18:50:57 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <3CFC2F81637043999463748C4C8A0B88@cr3lt> References: <3CFC2F81637043999463748C4C8A0B88@cr3lt> Message-ID: <20081128235725.GM27887@scytale.galois.com> claus.reinke: > >But I don't want Perl, I want a well designed language and well > >designed libraries. > >I think it's find to let libraries proliferate, but at some point you > >also need to step back and abstract. > > > > -- Lennart > > Especially so if the free marketeers claim there is something > fundamentally wrong with the standard libraries and language, as in > the case of arrays. When someone did that nice little survey of the > last bunch of array libraries (Bulat, I think? now in the wiki book), > I was hoping there would be a grand unification soon. Instead, it > seems that those who have worked most with Haskell arrays > recently have simply abandoned all of the standard array libraries. I don't think Bulat uploaded his libraries to hackage in the end. And if it's not on hackage, then no one will use it, so it may as well not exist. > Okay, why not, if there are good reasons. But can't you document > those reasons, for each of your alternative proposals, so that people > have some basis on which to choose (other than who has the loudest > market voice;-)? And would it be difficult for you all to agree on a > standard API, to make switching between the alternatives easy (if > it is indeed impossible to unify their advantages in a single library, > the reasons for which should also be documented somewhere)? > And what is wrong about Simon's suggestion, to use the standard > array lib APIs on top of your implementations? Nothing. This would be great. Who's volunteering to write the code? The new 'list-like' fusible array libraries are still in alpha, anyway. > Not that I see Haskell' coming soon, but I'd certainly not want it > to continue standardising a kind of array that appears to have no > backing among the Haskell array user/library author community. Nor > would I like something as central as arrays to remain outside the > standard, where it won't remain stable enough for Haskell > programmers to rely on in the long run. Hence the Haskell Platform. To provide the stability that people rely on in the long run. Haskell' is not the process by which new libraries will be standardised -- there's simply too many libraries being produced. The platform let's us: * Take libraries out of the standardisation process. * Let developers develop in competition, and converge on agreed designs. * Let users decide what to use, rather than waste time standardising things when the developer community has already moved on. * And then publish a list of blessed code. Since arrays are just another (non-obvious) data structure, there's a huge design space: * flat and/or nested arrays? * strict or lazy or eager? * callable from C or Fortran? * mutable/immutable * polymorphic in what dimensions? * mmap-able? * read / write API, or list-like API? We've not yet found the perfect implementation, but we're learning a lot. And since it is not yet clear what the optimal solution looks like, I say let the developers keep hacking for a while, until we get an idea of what works. And by all means, if someone thinks they know what the best API is, step up and show us the implementation! -- Don From rl at cse.unsw.edu.au Fri Nov 28 19:00:38 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Fri Nov 28 18:54:40 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <3CFC2F81637043999463748C4C8A0B88@cr3lt> References: <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <492EAC58.5080207@gmail.com><718AAA7EDD8244709E670ACE86B80C29@cr3lt><7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au><492FB41B.6000700@gmail.com><493065FE.2090003@btinternet.com><20081128214611.GD27887@scytale.galois.com> <3CFC2F81637043999463748C4C8A0B88@cr3lt> Message-ID: <024D3792-3FF7-43AC-AD89-281D26AF958F@cse.unsw.edu.au> On 29/11/2008, at 10:47, Claus Reinke wrote: >> But I don't want Perl, I want a well designed language and well >> designed libraries. >> I think it's find to let libraries proliferate, but at some point you >> also need to step back and abstract. >> -- Lennart > > Especially so if the free marketeers claim there is something > fundamentally wrong with the standard libraries and language, as in > the case of arrays. When someone did that nice little survey of the > last bunch of array libraries (Bulat, I think? now in the wiki > book), I was hoping there would be a grand unification soon. > Instead, it seems that those who have worked most with Haskell > arrays recently have simply abandoned all of the standard array > libraries. > Okay, why not, if there are good reasons. But can't you document > those reasons, for each of your alternative proposals, so that > people have some basis on which to choose (other than who has the > loudest market voice;-)? I think so far, it's always been the same two reasons: efficiency and ease of use. H98 arrays are inherently inefficient and IMO not very easy to use, at least not for the things that I'm doing. > And would it be difficult for you all to agree on a standard API, to > make switching between the alternatives easy (if > it is indeed impossible to unify their advantages in a single library, > the reasons for which should also be documented somewhere)? Yes, it is very difficult. A sensible API for a standard array library is something that needs more research. FWIW, I don't know of any other language that has what I'd like to see in Haskell. C++ probably comes closest but they have it easy - they don't do fusion. > And what is wrong about Simon's suggestion, to use the standard > array lib APIs on top of your implementations? Again, IMO H98 arrays are only suitable for a very restricted set of array algorithms. Roman From dons at galois.com Fri Nov 28 19:15:30 2008 From: dons at galois.com (Don Stewart) Date: Fri Nov 28 19:09:36 2008 Subject: [Haskell-cafe] ANNOUNCE: Haskell Communities and Activities Report (15th ed., November 2008) In-Reply-To: <492F9701.9010707@tcs.inf.tu-dresden.de> References: <492F9701.9010707@tcs.inf.tu-dresden.de> Message-ID: <20081129001530.GN27887@scytale.galois.com> Good work! It is always interesting to see the secret Haskell projects that only get announced via the HCAR. Things not on haskell@ or on hackage. For example, this under-the-radar project: http://www.haskell.org/communities/11-2008/html/report.html#sect7.7 7.7 IVU Traffic Technologies AG Rostering Group Haskell to solve constraints on EU bus timetables! In production use! -- Don voigt: > On behalf of the many, many contributors, I am pleased to announce > that the > > Haskell Communities and Activities Report > (15th edition, November 2008) > > http://www.haskell.org/communities/ > > is now available from the Haskell Communities home page in PDF and > HTML formats. From claus.reinke at talk21.com Fri Nov 28 19:49:21 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Nov 28 19:43:05 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries References: <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com><492EAC58.5080207@gmail.com><718AAA7EDD8244709E670ACE86B80C29@cr3lt><7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au><492FB41B.6000700@gmail.com><493065FE.2090003@btinternet.com><20081128214611.GD27887@scytale.galois.com><3CFC2F81637043999463748C4C8A0B88@cr3lt> <024D3792-3FF7-43AC-AD89-281D26AF958F@cse.unsw.edu.au> Message-ID: <1DC5B59351E74783A73F89A083BBB272@cr3lt> > Yes, it is very difficult. A sensible API for a standard array library > is something that needs more research. FWIW, I don't know of any other > language that has what I'd like to see in Haskell. C++ probably comes > closest but they have it easy - they don't do fusion. I assume you've looked at SAC? http://www.sac-home.org/ Their main research and development focus was/has been on arrays (fusion/layout/padding/tiling/slicing/data-parallelism/shape-invariance (source algorithms parameterized over array dimensionality/shape)/ whole-array ops/list-like ops/lots of surface operations reducable to a minimal set of core operations that need implementation/cache behaviour/performance/performance/performance/..). When they started out, I tried to make the point that I would have liked to have their wonderful array ideas in our otherwise wonderful language, but they preferred to follow their own way towards world domination (*). Does that sound familiar?-) Claus (*) ok, they did have a good motive: they came out of a research group that had done non-sequential functional programming in the 1980s, with all the things we see today: great speedups, shame about the sequential baseline; creating parallel threads is easy, load balancing slightly harder, but pumping (creating thread hierarchies recursively, only to see them fold into a small result, for the process to begin again) is a waste, etc.; so they decided to start from a fast sequential baseline instead of full functional language, and designed their language around arrays instead of trying to add arrays to an existing language. From kyagrd at gmail.com Fri Nov 28 20:49:49 2008 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Fri Nov 28 20:42:59 2008 Subject: [Haskell-cafe] Re: ANN: "Real World Haskell", now shipping In-Reply-To: <492DC16E.8050606@btinternet.com> References: <492DC16E.8050606@btinternet.com> Message-ID: Andrew Coppin ? ?: > > Then again, one day I sat down and tried to draw a diagram of the > essential concepts, techniques and syntax of Haskell and how they're > related... The result looked like alphabet soup! It's not clear how you > start to explain anything without immediately needing to explain 20 > other things you just used to explain the first thing. (Somebody > commented "recursive tutorials for a recursive language". It was meant > as an insult, but I actually kinda like it...) Given that that's the > case, I'm not really sure that I could do any better than the Three > Kings, so maybe I should just shuffle off and keep my comments to > myself. :-/ If one needs introductory Haskell programming tutorial explaining about the language concepts from first principles, then one should read a textbook written for that purpose such as "Programming in Haskell". "Real World Haskell" is a collection of practical tips and know-hows to get things done at work rather than a step-by-step Haskell tutorial. And I believe that many other O'Reilly books are like that. > What I *haven't* done yet is read the chapters where they try to claim > that database programming is possible in Haskell. I'll have to do that > at some point. Maybe this is where they reveal the Secret Formula that > makes this stuff actually work properly... but somehow I doubt it. What do you mean by that "they are trying database programming is possible in Haskell"? I've done very simple database programming in Haskell using HDBC, and it just works using the binary package from debian. If you need more complicated examples, you can take a look at the hpodder source code or any other applications that use database. They are all on Hackage. -- Ahn, Ki Yung From john at repetae.net Fri Nov 28 22:30:18 2008 From: john at repetae.net (John Meacham) Date: Fri Nov 28 22:23:53 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DC605.4030602@btinternet.com> <62A837ED-079C-4E15-8863-75AFCDA4BF28@cs.otago.ac.nz> Message-ID: <20081129033017.GB31753@sliver.repetae.net> On Wed, Nov 26, 2008 at 07:20:12PM -0800, Jason Dagit wrote: > I spoke with the author of the fork a bit in IRC around the time it happened > and my understanding is that: > 1) John sternly objects to using cabal as the build system for JHC This is a fairly silly reason to fork a project, especially jhc, for a number of reasons. It is important to me that jhc be as widely accessible at possible. The number of machines './configure && make install' will work on outnumbers those that cabal install will work on hundreds or thousands to one. I am pleased to have anyone experiment with jhc in the first place, I don't want to make things harder for my users. This alone would be enough of a reason all other things being equal, but other things arn't equal to boot. The quality of support I can provide is diminished with cabal. Someone tries to compile jhc, they get a moderately tricky build error. they send it to me, I take a look, figure out the workaround and release a new version that same day. one day turnaround. A bug is found in the way cabal does something. I track down the bug, hope it is something fixable, then further hope when I send a fix it is accepted. Maybe it takes a week or two. Now, do I release a new version of jhc that requires a development version of cabal? do I hold off and tell the user they need a personalized workaround? do I demand that to use jhc you have to use the latest cabal snapshots? Do I then have to support them when the latest snapshots break something else of theirs? In any case. it is not a situation I want to be in. Cabal just isn't elegant. let's put it in perspective, cabal has 4 times as many lines of code as mk (a superset of make)*. That is four times as many lines of haskell code as C. Given how much more dense and expressive haskell code is than C, that is a huge amount. Yet cabal can't handle what even mildly complicated make scripts can do. Cabal is not flexible. I decide I want to include a nice graph of code motion in jhc, so I add the following 2 lines to my makefile > %.pdf: %.dot > dot $< -Tpdf -o$@ and done! my build system now understands how to create pdf documents from graph description files. now, I _could_ add support for this to cabal, I _could_ wait several months for the new version to propagate to users. And I _would_ fully expect to have to go through the whole process again the next time I want to do something slightly unorthodox. Cabal is just a huge dependency I don't need. Every dependency I add to a project is a bigger hassle for my users and for me. A fairly complicated dependency like cabal would have to have fairly compelling benefits. Now, I am saying these things so people don't think I am just being stubborn. I have valid, compelling, and logical reasons to not want to use cabal. I think it is the wrong tool for the job and it is that simple. If you want me to switch to cabal, address its issues, and then _in addition_ add a killer feature on top to put it ahead of other systems to make the work involved in switching worth it. I have a goal with jhc, to write a kick ass haskell compiler. Not to fight a build system that is not suited to my task and that made some dubious design decisions. Not to promote an agenda. And before you respond, think about this. What if the ghc developers were constantly bombarded with whining from the perl people that ghc doesn't use MakeMaker.pm since ghc uses perl in the evil demangler? What would your impression of the perl community be? What if people kept trying to convince _you_ to rewrite your haskell project in java _and_ provide support for it because "they never had to use referential transparency, so it can't be that important to you". Sometimes that is what it feels like, which is disapointing from this community. We all came to haskell because we thought it was the better choice at some point. The hegemony was pushing java, C++, or worse but we didn't bite (or at least were still hungry). Just because something is popular, it doesn't mean it is good, just because it is written in haskell, it doesn't mean it is elegant. So don't begrudge me for holding out for something better. Perhaps franchise will be it, perhaps some future version of cabal, perhaps nothing will replace make/autoconfs sweet spot (though I would hope there is still some innovation in this area the OSS community can explore). > I hope John doesn't take the fork as any sort of aggressive or insulting > action. He's made a compiler that is sufficiently interesting to have users > that want to take over. I am still actively working on jhc for the record. Actual code checkin tends to be very spurty, but don't think the project is dead. More in a design phase than anything else. There is no surer way to instigate another spurt than by submitting some patches or bringing up discussion of an interesting topic or paper on the jhc mailing list. John * if you include the source of all the libraries mk depends on, cabal still has twice as many lines. -- John Meacham - ?repetae.net?john? From dons at galois.com Fri Nov 28 22:41:42 2008 From: dons at galois.com (Don Stewart) Date: Fri Nov 28 22:35:13 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <20081129033017.GB31753@sliver.repetae.net> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DC605.4030602@btinternet.com> <62A837ED-079C-4E15-8863-75AFCDA4BF28@cs.otago.ac.nz> <20081129033017.GB31753@sliver.repetae.net> Message-ID: <20081129034142.GR27887@scytale.galois.com> john: > On Wed, Nov 26, 2008 at 07:20:12PM -0800, Jason Dagit wrote: > > I spoke with the author of the fork a bit in IRC around the time it happened > > and my understanding is that: > > 1) John sternly objects to using cabal as the build system for JHC > > This is a fairly silly reason to fork a project, especially jhc, for a > number of reasons. One of the reasons though, for the branching, is that the potential developers, who all have Haskell toolchains, couldn't do: $ cabal install jhc Then now can, but have to write 'lhc' instead of 'jhc'. We've probably just increased the jhc "alpha user" base 10 fold. Hooray! Integrating into the ecology of the vast majority of Haskell code is a good way to get and keep developers. And since GHC -- which we need to build JHC anyway -- already ships with Cabal, no additional dependencies are required. Looks like win to me. -- Don From dagit at codersbase.com Fri Nov 28 23:51:45 2008 From: dagit at codersbase.com (Jason Dagit) Date: Fri Nov 28 23:45:25 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <20081129033017.GB31753@sliver.repetae.net> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DC605.4030602@btinternet.com> <62A837ED-079C-4E15-8863-75AFCDA4BF28@cs.otago.ac.nz> <20081129033017.GB31753@sliver.repetae.net> Message-ID: On Fri, Nov 28, 2008 at 7:30 PM, John Meacham wrote: > On Wed, Nov 26, 2008 at 07:20:12PM -0800, Jason Dagit wrote: > > I spoke with the author of the fork a bit in IRC around the time it > happened > > and my understanding is that: > > 1) John sternly objects to using cabal as the build system for JHC > > This is a fairly silly reason to fork a project, especially jhc, for a > number of reasons. > > It is important to me that jhc be as widely accessible at possible. The > number of machines './configure && make install' will work on outnumbers > those that cabal install will work on hundreds or thousands to > one. I am pleased to have anyone experiment with jhc in the first place, I > don't want to make things harder for my users. This alone would be > enough of a reason all other things being equal, but other things arn't > equal to boot. The command './configure && make install' only works in Windows if the user bother to install some form of unix environment emulation like msys or cygwin. I don't know if windows platform support matters to jhc, but if it does that's one reason to want to provide an alternative to the autotools build option. > > > The quality of support I can provide is diminished with cabal. Someone > tries to compile jhc, they get a moderately tricky build error. they > send it to me, I take a look, figure out the workaround and release a > new version that same day. one day turnaround. A bug is found in the way > cabal does something. I track down the bug, hope it is something > fixable, then further hope when I send a fix it is accepted. Maybe it > takes a week or two. Now, do I release a new version of jhc that > requires a development version of cabal? do I hold off and tell the user > they need a personalized workaround? do I demand that to use jhc you > have to use the latest cabal snapshots? Do I then have to support them > when the latest snapshots break something else of theirs? In any case. > it is not a situation I want to be in. > > Cabal just isn't elegant. let's put it in perspective, cabal has 4 times > as many lines of code as mk (a superset of make)*. That is four times as > many lines of haskell code as C. Given how much more dense and > expressive haskell code is than C, that is a huge amount. Yet cabal > can't handle what even mildly complicated make scripts can do. > > > Cabal is not flexible. I decide I want to include a nice graph of code > motion in jhc, so I add the following 2 lines to my makefile > > > %.pdf: %.dot > > dot $< -Tpdf -o$@ > > and done! my build system now understands how to create pdf documents > from graph description files. now, I _could_ add support for this to > cabal, I _could_ wait several months for the new version to propagate to > users. And I _would_ fully expect to have to go through the whole > process again the next time I want to do something slightly unorthodox. > > > Cabal is just a huge dependency I don't need. Every dependency I add to > a project is a bigger hassle for my users and for me. A fairly > complicated dependency like cabal would have to have fairly compelling > benefits. Your arguments make it sound as though providing an option for building with cabal is out of the question. Since I'm not invovled with JHC or LHC in any way I don't know how you would answer this question: Would you consider a cabal based build inaddition to the autotools one? Personally, I look at it this way. Both build systems have different advantages that the other cannot provide but they are not mutually exclusive. Also, the effort to keep them both working for the respective groups of users is rather small in practice. > > > Now, I am saying these things so people don't think I am just being > stubborn. I have valid, compelling, and logical reasons to not want to > use cabal. I think it is the wrong tool for the job and it is that > simple. If you want me to switch to cabal, address its issues, and > then _in addition_ add a killer feature on top to put it ahead of other > systems to make the work involved in switching worth it. I have a goal > with jhc, to write a kick ass haskell compiler. Not to fight a build > system that is not suited to my task and that made some dubious design > decisions. Not to promote an agenda. The reason to provide a .cabal file is exactly the one Don wrote about. This is possible both using make as the build system or in a way that is independent of the make based build system. > > > And before you respond, think about this. What if the ghc developers > were constantly bombarded with whining from the perl people that ghc > doesn't use MakeMaker.pm since ghc uses perl in the evil demangler? What > would your impression of the perl community be? I don't recall if I've expressed this publicly before or not, but I'm not fond of the language specific reimplementations of make. I think it's silly that every language has 2-3 language specific build systems and package formats. But, it's too late for me to stop Cabal from existing. Hackage is too useful to ignore. Using it increases my productivity. Tools that use the Cabal format save me time and give me cool features for free. I can easily run haddock or module graphs for example. So, in short, if the perl community had a compelling argument based on what GHC is missing out on, then I think it would be fine for them to bring that to the attention of GHC HQ. Now, the next point. I think you're getting carried away here. This fork was created without you being aware of it. That makes me think the author of the fork didn't bombard you with whining. So, I think we need to keep some perspective on that. It's natural that you should have a fair bit of emotional attachment to the JHC -- you'd be weird if you didn't -- but as I've said before, I don't think any of this is an attack on you or JHC. Rather I think it's a fondness for JHC plus a desire to try different things. > > > What if people kept trying to convince _you_ to rewrite your haskell > project in java _and_ provide support for it because "they never had to > use referential transparency, so it can't be that important to you". When this comes up on the Darcs mailing list we tend to explain why we like Haskell and then encourage them to try a reimplementation in their favorite language if they want to. I think that parallels the situation here. Someone thought he could do better by doing X and Y and instead of expecting you to support that went off and made a fork where he can support that. > > > Sometimes that is what it feels like, which is disapointing from this > community. We all came to haskell because we thought it was the better > choice at some point. The hegemony was pushing java, C++, or worse but > we didn't bite (or at least were still hungry). Just because something > is popular, it doesn't mean it is good, just because it is written in > haskell, it doesn't mean it is elegant. So don't begrudge me for holding > out for something better. Perhaps franchise will be it, perhaps some > future version of cabal, perhaps nothing will replace make/autoconfs > sweet spot (though I would hope there is still some innovation in this > area the OSS community can explore). Well, I came to Haskell because I had university courses that introduced me to it, then I started using Darcs and realized I wanted to contribute to Darcs so I learned more Haskell. In the process, my old favorite language Common Lisp was replaced by my new favorite Haskell. I tell people that I now prefer Haskell because: a) The static guarantees you can get really are useful b) the language and paradigm fit the way I think c) the community is full of exteremely intelligent people that care about the quality of the code they write d) the community is friendly and growing. I think animonsity towards Java and C++ is silly. Those languages have their merit, their strengths and their place. I don't see how using Cabal for it's strengths today and make for its strengths prevents you from using the next cool thing when it gets here. > > > I hope John doesn't take the fork as any sort of aggressive or insulting > > action. He's made a compiler that is sufficiently interesting to have > users > > that want to take over. > > I am still actively working on jhc for the record. Actual code checkin > tends to be very spurty, but don't think the project is dead. More in a > design phase than anything else. There is no surer way to instigate > another spurt than by submitting some patches or bringing up discussion > of an interesting topic or paper on the jhc mailing list. That's good to hear. Thanks for your time, and I wish both projects well with lots of collaboration! Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081128/a5c48d70/attachment.htm From jason.dusek at gmail.com Sat Nov 29 00:34:46 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sat Nov 29 00:28:21 2008 Subject: [Haskell-cafe] ANN: "Real World Haskell", now shipping In-Reply-To: <492DC16E.8050606@btinternet.com> References: <492DC16E.8050606@btinternet.com> Message-ID: <42784f260811282134l36e0043fo4424f775cd67a8b5@mail.gmail.com> Andrew Coppin wrote: > What I *haven't* done yet is read the chapters where they try > to claim that database programming is possible in Haskell. > I'll have to do that at some point. Maybe this is where they > reveal the Secret Formula that makes this stuff actually work > properly... but somehow I doubt it. Well, it's certainly possible to interact with a SQL database. You have had some kind of trouble, or you have a higher notion of "database programming"? -- _jsn From andrewcoppin at btinternet.com Sat Nov 29 04:25:03 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Nov 29 04:18:34 2008 Subject: [Haskell-cafe] ANN: "Real World Haskell", now shipping In-Reply-To: <42784f260811282134l36e0043fo4424f775cd67a8b5@mail.gmail.com> References: <492DC16E.8050606@btinternet.com> <42784f260811282134l36e0043fo4424f775cd67a8b5@mail.gmail.com> Message-ID: <49310A6F.7010809@btinternet.com> Jason Dusek wrote: > Andrew Coppin wrote: > >> What I *haven't* done yet is read the chapters where they try >> to claim that database programming is possible in Haskell. >> I'll have to do that at some point. Maybe this is where they >> reveal the Secret Formula that makes this stuff actually work >> properly... but somehow I doubt it. >> > > Well, it's certainly possible to interact with a SQL database. > You have had some kind of trouble, or you have a higher notion > of "database programming"? > Yeah: None of the packages on Hackage will compile successfully. :-P It seems to be an unwritten law that any package involving non-Haskell components doesn't work on Windoze. (Hack, wxHaskell even comes with a special pre-build Windows binary... and it *still* doesn't work!) From gianfranco.alongi at gmail.com Sat Nov 29 04:27:16 2008 From: gianfranco.alongi at gmail.com (Gianfranco Alongi) Date: Sat Nov 29 04:20:52 2008 Subject: [Haskell-cafe] ANN: "Real World Haskell", now shipping In-Reply-To: <49310A6F.7010809@btinternet.com> References: <492DC16E.8050606@btinternet.com> <42784f260811282134l36e0043fo4424f775cd67a8b5@mail.gmail.com> <49310A6F.7010809@btinternet.com> Message-ID: As far as I know, wxHaskell was developed mainly for windows? On Sat, Nov 29, 2008 at 10:25 AM, Andrew Coppin wrote: > Jason Dusek wrote: >> >> Andrew Coppin wrote: >> >>> >>> What I *haven't* done yet is read the chapters where they try >>> to claim that database programming is possible in Haskell. >>> I'll have to do that at some point. Maybe this is where they >>> reveal the Secret Formula that makes this stuff actually work >>> properly... but somehow I doubt it. >>> >> >> Well, it's certainly possible to interact with a SQL database. >> You have had some kind of trouble, or you have a higher notion >> of "database programming"? >> > > Yeah: None of the packages on Hackage will compile successfully. :-P > > It seems to be an unwritten law that any package involving non-Haskell > components doesn't work on Windoze. > > (Hack, wxHaskell even comes with a special pre-build Windows binary... and > it *still* doesn't work!) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Patience is the last resort for those unable to take action From andrewcoppin at btinternet.com Sat Nov 29 04:37:58 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Nov 29 04:31:31 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: References: <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> <492FB41B.6000700@gmail.com> <493065FE.2090003@btinternet.com> <20081128214611.GD27887@scytale.galois.com> Message-ID: <49310D76.1020702@btinternet.com> Lennart Augustsson wrote: > But I don't want Perl, I want a well designed language and well > designed libraries. > I think it's find to let libraries proliferate, but at some point you > also need to step back and abstract. > I agree. > On Fri, Nov 28, 2008 at 9:46 PM, Don Stewart wrote: > >> andrewcoppin: >> >>> What *I* propose is that somebody [you see what I did there?] should sit >>> down, take stock of all the multitudes of array libraries, what features >>> they have, what obvious features they're missing, and think up a good >>> API from scratch. Once we figure out what the best way to arrange all >>> this stuff is, *then* we attack the problem of implementing it for real. >>> >>> It seems lots of people have written really useful code, but we need to >>> take a step back and look at the big picture here before writing any >>> more of it. >>> >> No. >> >> My view would be to let the free market of developers decide what is >> best. No bottlenecks -- there's too many Haskell libraries already (~1000 now). >> >> And this approach has yielded more code than ever before, more libraries >> than ever before, and library authors are competing. >> >> So let the market decide. We're a bazaar, not a cathedral. >> I find this kind of attitude disturbing. Are you seriously asserting that it's "bad" for people to stop and think about their designs before building? That it's "bad" for people to get together and coordinate their efforts? Would you really prefer each and every developer to reinvent the wheel until we have 50,000 equivilent but slightly different wheel implementations? Certainly you seem obsessed with the notion that "more packages on Hackage == better". Well in my book, quantity /= quality. (The latter being vastly more important than the former - while admittedly far harder to measure objectively.) I would far prefer to see one well-written library that solves the problem properly than see 25 incompatible libraries that all solve small fragments of the problem poorly. In the latter case, there will be no "competition" between libraries; everybody will just give up and not use *any* of them. You _can_ have too much choice! I really hope I'm not the only person here who sees it this way... From dominic.steinitz at blueyonder.co.uk Sat Nov 29 04:32:28 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat Nov 29 04:37:34 2008 Subject: [Haskell-cafe] Control.Exception Funny Message-ID: <49310C2C.20505@blueyonder.co.uk> I'm probably doing something wrong but this example doesn't compile for me under ghc 6.10.1 (http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html#4): > catch (openFile f ReadMode) > (\e -> hPutStr stderr ("Couldn't open "++f++": " ++ show e)) > Run.hs:77:24: > Couldn't match expected type `Handle' against inferred type `()' > Expected type: IO Handle > Inferred type: IO () > In the expression: > hPutStr stderr ("Couldn't open " ++ d ++ ": " ++ show e) > In the second argument of `CE.catch', namely > `(\ e -> hPutStr stderr ("Couldn't open " ++ d ++ ": " ++ show e))' Fair enough because openFile returns a Handle and hPutStr returns () so they don't match as the compiler says. > CE.catch :: (CE.Exception e) => IO a -> (e -> IO a) -> IO a So if I fix the example thus: > foo d = CE.catch (openFile d ReadMode >> return ()) > (\e -> hPutStr stderr ("Couldn't open "++ d ++": " ++ show e)) I get > Run.hs:70:8: > Ambiguous type variable `e' in the constraint: > `CE.Exception e' > arising from a use of `CE.catch' at Run.hs:(70,8)-(71,78) > Probable fix: add a type signature that fixes these type variable(s) Now I think I never used to get this under 6.8.2 but I don't easily have a 6.8.2 to try it out on. Doing what the compiler suggests doesn't work for obvious reasons: > foo :: CE.Exception e => FilePath -> IO () > foo d = CE.catch (openFile d ReadMode >> return ()) > (\e -> hPutStr stderr ("Couldn't open "++ d ++": " ++ show e)) > Run.hs:69:0: > Ambiguous constraint `CE.Exception e' > At least one of the forall'd type variables mentioned by the constraint > must be reachable from the type after the '=>' > In the type signature for `foo': > foo :: (CE.Exception e) => FilePath -> IO () There seems to be a ticket for it (http://hackage.haskell.org/trac/ghc/ticket/2819) but this doesn't give a suggested example that compiles. Dominic. From john at repetae.net Sat Nov 29 05:41:32 2008 From: john at repetae.net (John Meacham) Date: Sat Nov 29 05:35:05 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <20081129034142.GR27887@scytale.galois.com> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DC605.4030602@btinternet.com> <62A837ED-079C-4E15-8863-75AFCDA4BF28@cs.otago.ac.nz> <20081129033017.GB31753@sliver.repetae.net> <20081129034142.GR27887@scytale.galois.com> Message-ID: <20081129104132.GC31753@sliver.repetae.net> On Fri, Nov 28, 2008 at 07:41:42PM -0800, Don Stewart wrote: > john: > > On Wed, Nov 26, 2008 at 07:20:12PM -0800, Jason Dagit wrote: > > > I spoke with the author of the fork a bit in IRC around the time it happened > > > and my understanding is that: > > > 1) John sternly objects to using cabal as the build system for JHC > > > > This is a fairly silly reason to fork a project, especially jhc, for a > > number of reasons. > > One of the reasons though, for the branching, is that the potential > developers, who all have Haskell toolchains, couldn't do: > > $ cabal install jhc > > Then now can, but have to write 'lhc' instead of 'jhc'. > > We've probably just increased the jhc "alpha user" base 10 fold. Hooray! Except that for all those systems that can use cabal, ./configure && make install would have already worked perfectly. So in actuality my alpha user base drops 50-fold. Also, I am not so sure who these people are who are willing to type 10 characters to try out jhc, but not a dozen more. I mean, a few typos and there won't be enough keystrokes in their budget to compile hello world, let alone provide a bug report or send a patch :) I think you are overestimating the penetration of cabal or underestimating the size and diversity of the haskell user base. There are a whole lot of people out there who just want to use haskell and don't keep up with the IRC channels or the mailing lists. Grad students interested in some aspect of jhcs design who did apt-get install ghc and then expect jhc to work. Sysadmins who manage clusters of computers for work but have no particular attachement to haskell whose kickstart scripts allow just dropping in an autoconfed tarball but have to be retooled for something new? > Integrating into the ecology of the vast majority of Haskell code is a > good way to get and keep developers. And since GHC -- which we need to > build JHC anyway -- already ships with Cabal, no additional dependencies > are required. But wouldn't it be nicer if Haskell fit into the ecology of OSS in general? Even better wouldn't it be nice if peoples first impression of haskell was not annoyance at having to build a package in some proprietary way , but rather being impressed with some piece of software and looking into its implementation and seeing how it got to be so good? No one when just trying to install a random program not knowing anything about the implementation gets excited at seeing that they have to learn some brand new way of getting it to work. For a standalone program like jhc, integrating with the open source community as a whole, and having the flexibility of working with the right tool for the task at hand are very desirable things. When it comes down to it, an actual reason to use cabal is not there, If the reason is to fit into the ecology of Haskell code, then my question is why is this ecology so distinct to begin with? What is wrong with haskell such that its world must be so disjoint from that of other languages? That seems to be the real WTF here that needs fixing. John -- John Meacham - ?repetae.net?john? From dagit at codersbase.com Sat Nov 29 06:03:23 2008 From: dagit at codersbase.com (Jason Dagit) Date: Sat Nov 29 05:56:58 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <20081129104132.GC31753@sliver.repetae.net> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DC605.4030602@btinternet.com> <62A837ED-079C-4E15-8863-75AFCDA4BF28@cs.otago.ac.nz> <20081129033017.GB31753@sliver.repetae.net> <20081129034142.GR27887@scytale.galois.com> <20081129104132.GC31753@sliver.repetae.net> Message-ID: On Sat, Nov 29, 2008 at 2:41 AM, John Meacham wrote: > On Fri, Nov 28, 2008 at 07:41:42PM -0800, Don Stewart wrote: > > john: > > > On Wed, Nov 26, 2008 at 07:20:12PM -0800, Jason Dagit wrote: > > > > I spoke with the author of the fork a bit in IRC around the time it > happened > > > > and my understanding is that: > > > > 1) John sternly objects to using cabal as the build system for JHC > > > > > > This is a fairly silly reason to fork a project, especially jhc, for a > > > number of reasons. > > > > One of the reasons though, for the branching, is that the potential > > developers, who all have Haskell toolchains, couldn't do: > > > > $ cabal install jhc > > > > Then now can, but have to write 'lhc' instead of 'jhc'. > > > > We've probably just increased the jhc "alpha user" base 10 fold. Hooray! > > Except that for all those systems that can use cabal, ./configure && > make install would have already worked perfectly. So in actuality my > alpha user base drops 50-fold. > > Also, I am not so sure who these people are who are willing to type 10 > characters to try out jhc, but not a dozen more. I mean, a few typos and > there won't be enough keystrokes in their budget to compile hello world, > let alone provide a bug report or send a patch :) > > > I think you are overestimating the penetration of cabal or > underestimating the size and diversity of the haskell user base. There > are a whole lot of people out there who just want to use haskell and > don't keep up with the IRC channels or the mailing lists. Grad students > interested in some aspect of jhcs design who did apt-get install ghc > and then expect jhc to work. Sysadmins who manage clusters of computers > for work but have no particular attachement to haskell whose kickstart > scripts allow just dropping in an autoconfed tarball but have to be > retooled for something new? > > > > Integrating into the ecology of the vast majority of Haskell code is a > > good way to get and keep developers. And since GHC -- which we need to > > build JHC anyway -- already ships with Cabal, no additional dependencies > > are required. > > But wouldn't it be nicer if Haskell fit into the ecology of OSS in > general? Even better wouldn't it be nice if peoples first impression of > haskell was not annoyance at having to build a package in some > proprietary way , but rather being impressed with some piece of software > and looking into its implementation and seeing how it got to be so good? > No one when just trying to install a random program not knowing anything > about the implementation gets excited at seeing that they have to learn > some brand new way of getting it to work. > > For a standalone program like jhc, integrating with the open source > community as a whole, and having the flexibility of working with the > right tool for the task at hand are very desirable things. > > When it comes down to it, an actual reason to use cabal is not there, If > the reason is to fit into the ecology of Haskell code, then my question > is why is this ecology so distinct to begin with? What is wrong with > haskell such that its world must be so disjoint from that of other > languages? That seems to be the real WTF here that needs fixing. When it comes down to it, I've just been down a slippery slope. The fact is, hackage works and hackage is a good reason to support cabal. I'd also so say this thread is no longer productive. A fork happened, the fork embraces cabal but jhc does not need to embrace cabal; end of story really. We all get what we want. Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081129/ecd40a66/attachment.htm From kili at outback.escape.de Sat Nov 29 06:30:39 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Sat Nov 29 06:28:46 2008 Subject: [Haskell-cafe] Cabal (was: Compilers) In-Reply-To: References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DC605.4030602@btinternet.com> <62A837ED-079C-4E15-8863-75AFCDA4BF28@cs.otago.ac.nz> <20081129033017.GB31753@sliver.repetae.net> Message-ID: <20081129113039.GA29053@petunia.outback.escape.de> On Fri, Nov 28, 2008 at 08:51:45PM -0800, Jason Dagit wrote: > Personally, I look at it this way. Both build systems have different > advantages that the other cannot provide but they are not mutually > exclusive. I don't see any advantage in Cabal, except that a .cabal file provides some metadata and dependency information that can help the build. > Also, the effort to keep them both working for the respective > groups of users is rather small in practice. At least in ghc, the mixture of make and Cabal was a huge failure. Ciao, Kili From claus.reinke at talk21.com Sat Nov 29 07:01:49 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Sat Nov 29 06:55:29 2008 Subject: [Haskell-cafe] Control.Exception Funny References: <49310C2C.20505@blueyonder.co.uk> Message-ID: <6339B42E0F6F4B3B9F43E6287BC46DC1@cr3lt> >> CE.catch :: (CE.Exception e) => IO a -> (e -> IO a) -> IO a > >> foo d = CE.catch (openFile d ReadMode >> return ()) >> (\e -> hPutStr stderr ("Couldn't open "++ d ++": " ++ show e)) btw, if your handler cannot return the same type as your action, is this the right place to catch the exceptions? >> Run.hs:70:8: >> Ambiguous type variable `e' in the constraint: >> `CE.Exception e' >> arising from a use of `CE.catch' at Run.hs:(70,8)-(71,78) >> Probable fix: add a type signature that fixes these type variable(s) > > Now I think I never used to get this under 6.8.2 but I don't easily have > a 6.8.2 to try it out on. That would be the new extensible exceptions - instead of a single non-extendable exception type (no ambiguities), there's now an extendable class of exceptions. > Doing what the compiler suggests doesn't work for obvious reasons: > >> foo :: CE.Exception e => FilePath -> IO () >> foo d = CE.catch (openFile d ReadMode >> return ()) >> (\e -> hPutStr stderr ("Couldn't open "++ d ++": " ++ show e)) > >> Run.hs:69:0: >> Ambiguous constraint `CE.Exception e' >> At least one of the forall'd type variables mentioned by the constraint >> must be reachable from the type after the '=>' >> In the type signature for `foo': >> foo :: (CE.Exception e) => FilePath -> IO () The suggestion was to fix the type 'e'. Neither your signature, nor your exception handler do that. I found the documentation less than helpful for this recent switch, but if you look at the instances of the Exception class: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html#1 you'll see 'IOException' listed, so 'show (e::IOException)' might do what you want. > There seems to be a ticket for it > (http://hackage.haskell.org/trac/ghc/ticket/2819) but this doesn't give > a suggested example that compiles. I've annotated the ticket. Please check whether the suggested explanation would be helpful, and report any other places that have not been updated to the new exception system. Claus From rl at cse.unsw.edu.au Sat Nov 29 07:06:06 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Sat Nov 29 06:59:54 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <1DC5B59351E74783A73F89A083BBB272@cr3lt> References: <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com><492EAC58.5080207@gmail.com><718AAA7EDD8244709E670ACE86B80C29@cr3lt><7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au><492FB41B.6000700@gmail.com><493065FE.2090003@btinternet.com><20081128214611.GD27887@scytale.galois.com><3CFC2F81637043999463748C4C8A0B88@cr3lt> <024D3792-3FF7-43AC-AD89-281D26AF958F@cse.unsw.edu.au> <1DC5B59351E74783A73F89A083BBB272@cr3lt> Message-ID: On 29/11/2008, at 11:49, Claus Reinke wrote: >> Yes, it is very difficult. A sensible API for a standard array >> library is something that needs more research. FWIW, I don't know >> of any other language that has what I'd like to see in Haskell. C+ >> + probably comes closest but they have it easy - they don't do >> fusion. > > I assume you've looked at SAC? http://www.sac-home.org/ Yes. They have it even easier - they don't have polymorphism, they don't have higher-order functions, they don't have boxing and laziness and in a sense, they don't even do general-purpose programming, just scientific algorithms. And they have no existing language to integrate their stuff with. This is not to imply that their work isn't interesting and valuable; IMO, it just doesn't really help us when it comes to designing a Haskell array library. Roman From lemming at henning-thielemann.de Sat Nov 29 07:36:36 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Nov 29 07:30:12 2008 Subject: [Haskell-cafe] Extensible Exceptions In-Reply-To: <1227402420.7124.260.camel@localhost> References: <1227313177.3309.6.camel@Congo> <4927609F.5080104@z.odi.ac> <916b84820811220333q7c2605efl76d51cea7d0f3df4@mail.gmail.com> <916b84820811221525y615de18dg7b756ff74ea0bd26@mail.gmail.com> <1227402420.7124.260.camel@localhost> Message-ID: On Sun, 23 Nov 2008, Duncan Coutts wrote: > On Sun, 2008-11-23 at 01:40 +0100, Henning Thielemann wrote: >> On Sat, 22 Nov 2008, Thomas Schilling wrote: >> >>> It's a pattern match error, implemented by throwing an asynchronous >>> exception. The idea being, that we only have one mechanism (well, an >>> synchronous exceptions, thrown via throwIO). >>> >>> Yes, I know that there's a difference between "error" and "exception", >>> but I would argue that which is which depends on the program. For >>> example, for most programs a pattern match error is a fatal condition, >>> there's no sane recovery from it. OTOH, in a program like GHCi, a >>> pattern match error in an executed statement is an exceptional >>> condition, which we want to catch, so it doesn't kill GHCi. >> >> It's completely ok to run something in a sandbox and try to observe >> errors. But that's debugging and I think there is no need to do this in >> many places of an application. In general handling errors automatically is >> not possible, because an error might also be if a program loops >> infinitely. Thus one should not generally handle an error like an >> exception. > > In general I agree. I would advise against explicitly catching such > exceptions just in the region where one is expecting them. That seems > like bad design. > > On the other hand "top level" catch-all handlers that also catch such > logic errors sometimes make sense. For example in a Haskell web server > where we generate a page dynamically it makes a lot of sense to catch > errors in the page-generation function, including pattern match errors, > and produce a 500 error code response and log the error message. > > That's a case, rather like ghci, where some flaw in the program can and > should be compartmentalised. There's no attempt to clean up the error > but it is a modular system and there is a clear boundary where failures > can occur without bringing down the entire system. full acknowledge From yrn001 at gmail.com Sat Nov 29 07:49:48 2008 From: yrn001 at gmail.com (Jeroen Baekelandt) Date: Sat Nov 29 07:43:30 2008 Subject: [Haskell-cafe] GHC 6.10.1 multi-threaded broken? Message-ID: Hi, Since I upgraded from ghc 6.8.3 to 6.10.1, I noticed that my programs do not run multi-threaded anymore. I tried simplifying my code, till I just took one of the par/pseq demo's to verify if it wasn't my fault. When I compile this code on 6.8.3 (both ubuntu and OS X), top shows something like 180% CPU usage and the elapsed time is almost halved. When compiled with 6.10.1, top shows max 100% and no speedup is noticable at all. Sample run: $ ghc --make -threaded paralleltest $ time ./paralleltest +RTS -N1 -RTS 119201850 real 0m26.024s user 0m25.494s sys 0m0.220s $ time ./paralleltest +RTS -N2 -RTS 119201850 real 0m25.770s user 0m25.539s sys 0m0.167s I have the same on OS X and Ubuntu. I even compiled the Ubuntu ghc from source myself and verified that GMP was used. Any ideas? Thanks, Jeroen Here's the code: module Main where import Control.Parallel fib :: Int -> Int fib 0 = 0 fib 1 = 1 fib n = fib (n - 1) + fib (n - 2) mkList :: Int-> [Int] mkList n = [1..n-1] relprime :: Int -> Int -> Bool relprime x y = gcd x y == 1 euler :: Int -> Int euler n = length (filter (relprime n) (mkList n)) sumEuler :: Int -> Int sumEuler = sum . (map euler) . mkList parSumFibEuler :: Int -> Int -> Int parSumFibEuler a b = f `par` (e `pseq` (e + f)) where f = fib a e = sumEuler b main = do print $ parSumFibEuler 40 7450 From john at repetae.net Sat Nov 29 08:29:03 2008 From: john at repetae.net (John Meacham) Date: Sat Nov 29 08:22:38 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DC605.4030602@btinternet.com> <62A837ED-079C-4E15-8863-75AFCDA4BF28@cs.otago.ac.nz> <20081129033017.GB31753@sliver.repetae.net> Message-ID: <20081129132903.GE31753@sliver.repetae.net> On Fri, Nov 28, 2008 at 08:51:45PM -0800, Jason Dagit wrote: > On Fri, Nov 28, 2008 at 7:30 PM, John Meacham wrote: > > It is important to me that jhc be as widely accessible at possible. The > > number of machines './configure && make install' will work on outnumbers > > those that cabal install will work on hundreds or thousands to > > one. I am pleased to have anyone experiment with jhc in the first place, I > > don't want to make things harder for my users. This alone would be > > enough of a reason all other things being equal, but other things arn't > > equal to boot. > > The command './configure && make install' only works in Windows if the user > bother to install some form of unix environment emulation like msys or > cygwin. I don't know if windows platform support matters to jhc, but if it > does that's one reason to want to provide an alternative to the autotools > build option. This always seemed like a rather weak argument, first of all, it's not all that tricky to make autotools builds work on windows. Also, Windows users by far prefer binary distributions anyway. They are downloading the msi's rather than the source code. People who are actively developing a project generally have a more advanced toolchain anyway. Not that an easier windows build isn't useful, but that slightly easier windows build is outweighed by the much more complicated build system dependencies that are paid everywhere. > Your arguments make it sound as though providing an option for building with > cabal is out of the question. Since I'm not invovled with JHC or LHC in any > way I don't know how you would answer this question: Would you consider a > cabal based build inaddition to the autotools one? > > Personally, I look at it this way. Both build systems have different > advantages that the other cannot provide but they are not mutually > exclusive. Also, the effort to keep them both working for the respective > groups of users is rather small in practice. This is sort of like splitting the baby, I don't think the effort is really that small. A build system is a fairly complicated piece of code, and it is also one of the parts I want more than anything to 'just work' and having to worry about two different systems would not be productive. A dumbed down build that is the intersection of both systems would be barely usable and a drain on development effort. I never was opposed to a cabal 'target' for jhc. I have 'make dist' 'make dist-rpm' and hopefully 'make msi' soon, adding a 'make dist-hackage' alongside is not a bad thing, however, it is if it complicates the standard build or comes to dominate development effort or can't be done without duplication of functionality. Cabal is not entirely conducive to being used in this way at the moment, but this can be improved on. Some of the issues arn't too hard and perhaps are being worked on, like adding a 'hackage release' field, and a separate 'hackage' and 'project' maintainer fields. Others are trickier, like the requirement to conform to hackages version numbering policy that might differ from the native one. workarounds are possible of course. But again, this is work. Even if the code isn't that much, it does place a support burden on me and other jhc developers, so it isn't something I'd do on a whim and without a clean design that does not introduce any cabal dependencies on the standard build or require ongoing support that is more than minimal, in fact, the only time cabal should be invoked is specifically the case of installing via cabal-install. > > And before you respond, think about this. What if the ghc developers > > were constantly bombarded with whining from the perl people that ghc > > doesn't use MakeMaker.pm since ghc uses perl in the evil demangler? What > > would your impression of the perl community be? > > > I don't recall if I've expressed this publicly before or not, but I'm not > fond of the language specific reimplementations of make. I think it's silly > that every language has 2-3 language specific build systems and package > formats. But, it's too late for me to stop Cabal from existing. I totally agree. > Hackage is > too useful to ignore. Using it increases my productivity. Tools that use > the Cabal format save me time and give me cool features for free. I can > easily run haddock or module graphs for example. So, in short, if the perl > community had a compelling argument based on what GHC is missing out on, > then I think it would be fine for them to bring that to the attention of GHC > HQ. > > Now, the next point. I think you're getting carried away here. This fork > was created without you being aware of it. That makes me think the author > of the fork didn't bombard you with whining. So, I think we need to keep > some perspective on that. It's natural that you should have a fair bit of > emotional attachment to the JHC -- you'd be weird if you didn't -- but as > I've said before, I don't think any of this is an attack on you or JHC. > Rather I think it's a fondness for JHC plus a desire to try different > things. Yeah, I should say that this wasn't really directed at Lemmih and the other lhc authors. There actually was some discussion between me and him, a fork was mentioned, I did not know it was followed through on though until I saw this thread. To reiterate, Lemmih has made some great contributions to jhc, I fully support diversity in projects, so welcome the new effort. As long as the codebases are still compatible I expect patches to flow both directions. However, the issues I raised with cabal are real ones that concern me. Not just when it relates to jhc, but to the future of the language as a whole. There have been a number of projects I have been involved with where things did get as bad as I implied above. If the only reason for the fork was cabal, then that is disapointing. But I don't think that is entirely the case. John -- John Meacham - ?repetae.net?john? From jason.dusek at gmail.com Sat Nov 29 09:55:06 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sat Nov 29 09:48:40 2008 Subject: [Haskell-cafe] ANN: "Real World Haskell", now shipping In-Reply-To: <49310A6F.7010809@btinternet.com> References: <492DC16E.8050606@btinternet.com> <42784f260811282134l36e0043fo4424f775cd67a8b5@mail.gmail.com> <49310A6F.7010809@btinternet.com> Message-ID: <42784f260811290655j6b2f9300gbf43c8b2ac445f89@mail.gmail.com> Andrew Coppin wrote: > It seems to be an unwritten law that any package involving > non-Haskell components doesn't work on Windoze. Well, I'll have a chance to verify this soon enough. Have you posted your errors somewhere? -- _jsn From duncan.coutts at worc.ox.ac.uk Sat Nov 29 10:05:04 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Nov 29 09:58:42 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <20081129033017.GB31753@sliver.repetae.net> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DC605.4030602@btinternet.com> <62A837ED-079C-4E15-8863-75AFCDA4BF28@cs.otago.ac.nz> <20081129033017.GB31753@sliver.repetae.net> Message-ID: <1227971104.10115.77.camel@localhost> On Fri, 2008-11-28 at 19:30 -0800, John Meacham wrote: > On Wed, Nov 26, 2008 at 07:20:12PM -0800, Jason Dagit wrote: > > I spoke with the author of the fork a bit in IRC around the time it happened > > and my understanding is that: > > 1) John sternly objects to using cabal as the build system for JHC > > This is a fairly silly reason to fork a project, especially jhc, for a > number of reasons. In general John is right in most of his criticisms of Cabal. As someone who works on Cabal I am well aware of the problems in its design and implementation. I happen to think that most of the problems can be fixed but it would be silly to suggest that the balance of advantages to disadvantages goes in its favour for every project. The advantages at the moment are greatest for small projects and are in a large part due to network effects. The major problems are in the configuration and build components. The configuration language is not quite expressive enough and the current configuration search implementation does not take advantage of the full expressiveness of the existing language. The build component obviously should be based on a dependency system, as make is, rather than IO () and ghc --make. There are lots of things we don't do well because of this. As I said, I think all these things are fixable. But it is a lot of work. We're currently limited by the amount of developer time we have. So I would like to encourage people to get involved. There are elegant solutions to the problems. It's actually quite fun working on the new bits and helping to drain the IO () swamp. > It is important to me that jhc be as widely accessible at possible. The > number of machines './configure && make install' will work on outnumbers > those that cabal install will work on hundreds or thousands to > one. I've sometimes wondered why nobody has made a generic configure.ac and makefile that wraps the Cabal build procedure. It seems pretty straightforward and it might help lower barriers for some users, especially, as John mentions, potential users from outside the community. Duncan From duncan.coutts at worc.ox.ac.uk Sat Nov 29 10:11:29 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Nov 29 10:05:06 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: References: <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> <492FB41B.6000700@gmail.com> <493065FE.2090003@btinternet.com> <20081128214611.GD27887@scytale.galois.com> Message-ID: <1227971489.10115.84.camel@localhost> On Fri, 2008-11-28 at 22:20 +0000, Lennart Augustsson wrote: > But I don't want Perl, I want a well designed language and well > designed libraries. > I think it's find to let libraries proliferate, but at some point you > also need to step back and abstract. Yes, let the ideas simmer and when we can identify a consensus then we can standardise something by including it into the Haskell platform. There's obviously judgement involved to decide when it's right to standardise. We can see all around us the results of standardising too early or too late. Duncan From bulat.ziganshin at gmail.com Sat Nov 29 10:13:46 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Nov 29 10:09:31 2008 Subject: [Haskell-cafe] ANN: "Real World Haskell", now shipping In-Reply-To: <42784f260811290655j6b2f9300gbf43c8b2ac445f89@mail.gmail.com> References: <492DC16E.8050606@btinternet.com> <42784f260811282134l36e0043fo4424f775cd67a8b5@mail.gmail.com> <49310A6F.7010809@btinternet.com> <42784f260811290655j6b2f9300gbf43c8b2ac445f89@mail.gmail.com> Message-ID: <111142253.20081129181346@gmail.com> Hello Jason, Saturday, November 29, 2008, 5:55:06 PM, you wrote: >> It seems to be an unwritten law that any package involving >> non-Haskell components doesn't work on Windoze. > Well, I'll have a chance to verify this soon enough. Have you > posted your errors somewhere? unfortunately, HsLua already breaks the law :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From brad.larsen at gmail.com Sat Nov 29 10:43:45 2008 From: brad.larsen at gmail.com (Brad Larsen) Date: Sat Nov 29 10:37:21 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <024D3792-3FF7-43AC-AD89-281D26AF958F@cse.unsw.edu.au> References: <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> <492FB41B.6000700@gmail.com> <493065FE.2090003@btinternet.com> <20081128214611.GD27887@scytale.galois.com> <3CFC2F81637043999463748C4C8A0B88@cr3lt> <024D3792-3FF7-43AC-AD89-281D26AF958F@cse.unsw.edu.au> Message-ID: On Fri, 28 Nov 2008 19:00:38 -0500, Roman Leshchinskiy wrote: > On 29/11/2008, at 10:47, Claus Reinke wrote: [...] >> And would it be difficult for you all to agree on a standard API, to >> make switching between the alternatives easy (if >> it is indeed impossible to unify their advantages in a single library, >> the reasons for which should also be documented somewhere)? > > Yes, it is very difficult. A sensible API for a standard array library > is something that needs more research. FWIW, I don't know of any other > language that has what I'd like to see in Haskell. C++ probably comes > closest but they have it easy - they don't do fusion. [...] Would you elaborate on what you'd like to see in an array library? And perhaps which C++ array library you are thinking of? Your C++ comment caught my attention, and now I'm curious. Surely you don't mean C-style arrays. :-D Regards, Brad Larsen From duncan.coutts at worc.ox.ac.uk Sat Nov 29 11:49:52 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Nov 29 11:43:29 2008 Subject: [Haskell-cafe] ANN: "Real World Haskell", now shipping In-Reply-To: <111142253.20081129181346@gmail.com> References: <492DC16E.8050606@btinternet.com> <42784f260811282134l36e0043fo4424f775cd67a8b5@mail.gmail.com> <49310A6F.7010809@btinternet.com> <42784f260811290655j6b2f9300gbf43c8b2ac445f89@mail.gmail.com> <111142253.20081129181346@gmail.com> Message-ID: <1227977392.10115.87.camel@localhost> On Sat, 2008-11-29 at 18:13 +0300, Bulat Ziganshin wrote: > Hello Jason, > > Saturday, November 29, 2008, 5:55:06 PM, you wrote: > > >> It seems to be an unwritten law that any package involving > >> non-Haskell components doesn't work on Windoze. > > > Well, I'll have a chance to verify this soon enough. Have you > > posted your errors somewhere? > > unfortunately, HsLua already breaks the law :) How so? The hslua.cabal file labels it BSD3 where as it should be MIT. Is that what you meant? The COPYRIGHT file in the hslua package reproduces the lua licence. Duncan From bulat.ziganshin at gmail.com Sat Nov 29 11:57:07 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Nov 29 11:51:42 2008 Subject: [Haskell-cafe] ANN: "Real World Haskell", now shipping In-Reply-To: <1227977392.10115.87.camel@localhost> References: <492DC16E.8050606@btinternet.com> <42784f260811282134l36e0043fo4424f775cd67a8b5@mail.gmail.com> <49310A6F.7010809@btinternet.com> <42784f260811290655j6b2f9300gbf43c8b2ac445f89@mail.gmail.com> <111142253.20081129181346@gmail.com> <1227977392.10115.87.camel@localhost> Message-ID: <623994058.20081129195707@gmail.com> Hello Duncan, Saturday, November 29, 2008, 7:49:52 PM, you wrote: >> >> It seems to be an unwritten law that any package involving >> >> non-Haskell components doesn't work on Windoze. >> >> unfortunately, HsLua already breaks the law :) > How so? it has C code and works on windows -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Sat Nov 29 12:31:04 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Nov 29 12:24:53 2008 Subject: [Haskell-cafe] ANN: "Real World Haskell", now shipping In-Reply-To: <623994058.20081129195707@gmail.com> References: <492DC16E.8050606@btinternet.com> <42784f260811282134l36e0043fo4424f775cd67a8b5@mail.gmail.com> <49310A6F.7010809@btinternet.com> <42784f260811290655j6b2f9300gbf43c8b2ac445f89@mail.gmail.com> <111142253.20081129181346@gmail.com> <1227977392.10115.87.camel@localhost> <623994058.20081129195707@gmail.com> Message-ID: <1227979864.10115.91.camel@localhost> On Sat, 2008-11-29 at 19:57 +0300, Bulat Ziganshin wrote: > Hello Duncan, > > Saturday, November 29, 2008, 7:49:52 PM, you wrote: > > >> >> It seems to be an unwritten law that any package involving > >> >> non-Haskell components doesn't work on Windoze. > >> > >> unfortunately, HsLua already breaks the law :) > > > How so? > > it has C code and works on windows Oh, sorry, I misinterpreted what you said. "Law" made me think legal rather than the rule that Jason was positing. Other packages in that category include zlib and bzlib. Duncan From jwlato at gmail.com Sat Nov 29 13:08:17 2008 From: jwlato at gmail.com (John Lato) Date: Sat Nov 29 13:01:52 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries Message-ID: <9979e72e0811291008j4e4c126dm787da404da3a70@mail.gmail.com> > From: Andrew Coppin > >>> My view would be to let the free market of developers decide what is >>> best. No bottlenecks -- there's too many Haskell libraries already (~1000 now). >>> >>> And this approach has yielded more code than ever before, more libraries >>> than ever before, and library authors are competing. >>> >>> So let the market decide. We're a bazaar, not a cathedral. >>> > > I find this kind of attitude disturbing. > > Are you seriously asserting that it's "bad" for people to stop and think > about their designs before building? That it's "bad" for people to get > together and coordinate their efforts? Would you really prefer each and > every developer to reinvent the wheel until we have 50,000 equivilent > but slightly different wheel implementations? Certainly you seem > obsessed with the notion that "more packages on Hackage == better". Well > in my book, quantity /= quality. (The latter being vastly more important > than the former - while admittedly far harder to measure objectively.) I > would far prefer to see one well-written library that solves the problem > properly than see 25 incompatible libraries that all solve small > fragments of the problem poorly. In the latter case, there will be no > "competition" between libraries; everybody will just give up and not use > *any* of them. You _can_ have too much choice! > > I really hope I'm not the only person here who sees it this way... > I would love to see a perfect, unified array library in Haskell. I think everyone would. However, the problem Don, Roman, and others have raised is that there is no single consensus on what that library would look like, or how it would be implemented. It might be impossible for one library to fill the entire design space. Don's point is that, since this isn't yet a solved problem, having multiple implementations available to see what works well (and what doesn't) is a necessary step in finding a solution. I also think this is a exactly why Hackage needs a way to indicate that packages are deprecated/superceded by other packages. There was some talk about this recently, and IIRC even a submitted patch. I hope that gets adopted soon. John From andrewcoppin at btinternet.com Sat Nov 29 13:23:29 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Nov 29 13:16:58 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <9979e72e0811291008j4e4c126dm787da404da3a70@mail.gmail.com> References: <9979e72e0811291008j4e4c126dm787da404da3a70@mail.gmail.com> Message-ID: <493188A1.4020906@btinternet.com> John Lato wrote: > I would love to see a perfect, unified array library in Haskell. I > think everyone would. However, the problem Don, Roman, and others > have raised is that there is no single consensus on what that library > would look like, or how it would be implemented. It might be > impossible for one library to fill the entire design space. Don's > point is that, since this isn't yet a solved problem, having multiple > implementations available to see what works well (and what doesn't) is > a necessary step in finding a solution. > Interesting. I thought this was more or less a solved problem, it's just that nobody has yet had time to implement it all. I mean, the Haskell '98 array libraries are OK, they're just rather incomplete. We could do with the ability to have unboxed arrays of arbitrary types. (Remember, this is the default position in Pascal / C / C++ / most normal programming languages - although admittedly they don't have ADTs.) It would be useful to have the option to dispence with Ix. (And bounds checks, if you're sure you don't need them.) It would also be useful to be able to "slice" arrays. And we have the new parallel-array stuff coming now, but (AFAIK) it's fairly nontrivial to switch between normal arrays and parallel ones. Plus there are lots and lots of "obvious" and useful functions that aren't in the libraries. (E.g., in-place map for mutable arrays.) It seems silly to reimplement these every time you want to do something; they should be in the libraries. I doubt there will ever be a "perfect" library for anything. But that doesn't mean we can't take a few steps in the right direction. ;-) > I also think this is a exactly why Hackage needs a way to indicate > that packages are deprecated/superceded by other packages. There was > some talk about this recently, and IIRC even a submitted patch. I > hope that gets adopted soon. > Agreed. This goes beyond array libraries; do you have any idea how many "binary" packages there are? From mad.one at gmail.com Sat Nov 29 13:46:02 2008 From: mad.one at gmail.com (Austin Seipp) Date: Sat Nov 29 13:39:40 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <49310D76.1020702@btinternet.com> References: <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> <492FB41B.6000700@gmail.com> <493065FE.2090003@btinternet.com> <20081128214611.GD27887@scytale.galois.com> <49310D76.1020702@btinternet.com> Message-ID: <1227983084-sup-504@existential.local> Excerpts from Andrew Coppin's message of Sat Nov 29 03:37:58 -0600 2008: > Are you seriously asserting that it's "bad" for people to stop and think > about their designs before building? To be fair, I don't think you're in a position to say whether the authors of these libraries took careful consideration in their design or not; unless, of course, you wrote one of them and *didn't* think about the design? Austin From dons at galois.com Sat Nov 29 14:14:59 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 29 14:08:33 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <49310D76.1020702@btinternet.com> References: <492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> <492FB41B.6000700@gmail.com> <493065FE.2090003@btinternet.com> <20081128214611.GD27887@scytale.galois.com> <49310D76.1020702@btinternet.com> Message-ID: <20081129191459.GA30881@scytale.galois.com> andrewcoppin: > >> > >>My view would be to let the free market of developers decide what is > >>best. No bottlenecks -- there's too many Haskell libraries already (~1000 > >>now). > >> > >>And this approach has yielded more code than ever before, more libraries > >>than ever before, and library authors are competing. > >> > >>So let the market decide. We're a bazaar, not a cathedral. > >> > > I find this kind of attitude disturbing. > > Are you seriously asserting that it's "bad" for people to stop and think > about their designs before building? That it's "bad" for people to get > together and coordinate their efforts? Would you really prefer each and > every developer to reinvent the wheel until we have 50,000 equivilent Strawman, Andrew, and rather silly too. I'm aggressively in favour of reuse. That's why I advocate everyone use and contribute to Hackage, so that they can reuse other's work, and they can collaborate on existing code. The current approach of /people who do things/ is working very well. They're designing and implementing new ideas in the language, leading to interesting collaborations, and new designs, and more code, that does more things, than ever before. And I'm in favour of that. I never thought I'd say the day when people complained about there being too many libraries for Haskell. Mwhahaha! -- Don From dons at galois.com Sat Nov 29 14:27:15 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 29 14:20:44 2008 Subject: [Haskell-cafe] ANN: "Real World Haskell", now shipping In-Reply-To: <49310A6F.7010809@btinternet.com> References: <492DC16E.8050606@btinternet.com> <42784f260811282134l36e0043fo4424f775cd67a8b5@mail.gmail.com> <49310A6F.7010809@btinternet.com> Message-ID: <20081129192715.GB30881@scytale.galois.com> andrewcoppin: > Jason Dusek wrote: > >Andrew Coppin wrote: > > > >>What I *haven't* done yet is read the chapters where they try > >>to claim that database programming is possible in Haskell. > >>I'll have to do that at some point. Maybe this is where they > >>reveal the Secret Formula that makes this stuff actually work > >>properly... but somehow I doubt it. > >> > > > > Well, it's certainly possible to interact with a SQL database. > > You have had some kind of trouble, or you have a higher notion > > of "database programming"? > > > > Yeah: None of the packages on Hackage will compile successfully. :-P > > It seems to be an unwritten law that any package involving non-Haskell > components doesn't work on Windoze. > > (Hack, wxHaskell even comes with a special pre-build Windows binary... > and it *still* doesn't work!) Very curious. Did you file a bug report with the maintainers of the 30+ database packages on hackage? Or did you not have the underlying database drivers installed? Did you make any attempt to contact the authors to determine the cause of your problem? -- Don From dons at galois.com Sat Nov 29 14:31:52 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 29 14:25:23 2008 Subject: [Haskell-cafe] Cabal (was: Compilers) In-Reply-To: <20081129113039.GA29053@petunia.outback.escape.de> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DC605.4030602@btinternet.com> <62A837ED-079C-4E15-8863-75AFCDA4BF28@cs.otago.ac.nz> <20081129033017.GB31753@sliver.repetae.net> <20081129113039.GA29053@petunia.outback.escape.de> Message-ID: <20081129193152.GA30959@scytale.galois.com> kili: > On Fri, Nov 28, 2008 at 08:51:45PM -0800, Jason Dagit wrote: > > Personally, I look at it this way. Both build systems have different > > advantages that the other cannot provide but they are not mutually > > exclusive. > > I don't see any advantage in Cabal, except that a .cabal file > provides some metadata and dependency information that can help the > build. And we have tools to automate the packaging of cabal-specified code. So for example, there are already native packages of LHC, but not of JHC. http://aur.archlinux.org/packages.php?ID=21749 Because of the automatic packaging for cabal-specified software. -- Don From dons at galois.com Sat Nov 29 14:35:04 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 29 14:28:33 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <1227971104.10115.77.camel@localhost> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DC605.4030602@btinternet.com> <62A837ED-079C-4E15-8863-75AFCDA4BF28@cs.otago.ac.nz> <20081129033017.GB31753@sliver.repetae.net> <1227971104.10115.77.camel@localhost> Message-ID: <20081129193504.GB30959@scytale.galois.com> duncan.coutts: > > It is important to me that jhc be as widely accessible at possible. The > > number of machines './configure && make install' will work on outnumbers > > those that cabal install will work on hundreds or thousands to > > one. > > I've sometimes wondered why nobody has made a generic configure.ac and > makefile that wraps the Cabal build procedure. It seems pretty > straightforward and it might help lower barriers for some users, > especially, as John mentions, potential users from outside the > community. Yes. Reuse. That's why we moved to Cabal in the first place - to avoid reimplementing Makefiles, .hi rules, .o rules, and ld linking arguments once per Haskell library, which wasn't scalable in the slightest. We could come back, and have the 'make && make install' fans wrap up cabal with a generic wrapper for people who like to type 'make'. -- Don From andrewcoppin at btinternet.com Sat Nov 29 14:40:26 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Nov 29 14:33:54 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <1227983084-sup-504@existential.local> References: <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> <492FB41B.6000700@gmail.com> <493065FE.2090003@btinternet.com> <20081128214611.GD27887@scytale.galois.com> <49310D76.1020702@btinternet.com> <1227983084-sup-504@existential.local> Message-ID: <49319AAA.6030003@btinternet.com> Austin Seipp wrote: > Excerpts from Andrew Coppin's message of Sat Nov 29 03:37:58 -0600 2008: > >> Are you seriously asserting that it's "bad" for people to stop and think >> about their designs before building? >> > > To be fair, I don't think you're in a position to say whether the > authors of these libraries took careful consideration in their design > or not; unless, of course, you wrote one of them and *didn't* think > about the design? > I said "I think we should take a step back and work out a plan" and Don said "no, I think we should just keep blindly hacking away instead". So I said that seems like a very bad idea to me... From dons at galois.com Sat Nov 29 14:42:51 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 29 14:36:23 2008 Subject: [Haskell-cafe] GHC 6.10.1 multi-threaded broken? In-Reply-To: References: Message-ID: <20081129194251.GD30959@scytale.galois.com> yrn001: > Hi, > > Since I upgraded from ghc 6.8.3 to 6.10.1, I noticed that my programs > do not run multi-threaded anymore. I tried simplifying my code, till I just > took one of the par/pseq demo's to verify if it wasn't my fault. This sounds like the change to the scheduler where only 1 spark won't trigger the other core to wake up. See this mail from Simon Marlow, http://www.haskell.org/pipermail/haskell-cafe/2008-November/050974.html "I'll make sure it gets fixed for 6.10.2. If you have more sparks then you shouldn't see this problem. Also, GHC HEAD is quite a lot better with parallel programs than 6.10.1, I'll try to get around to posting some figures sometime." From dons at galois.com Sat Nov 29 14:48:52 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 29 14:42:21 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <49319AAA.6030003@btinternet.com> References: <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> <492FB41B.6000700@gmail.com> <493065FE.2090003@btinternet.com> <20081128214611.GD27887@scytale.galois.com> <49310D76.1020702@btinternet.com> <1227983084-sup-504@existential.local> <49319AAA.6030003@btinternet.com> Message-ID: <20081129194852.GF30959@scytale.galois.com> andrewcoppin: > Austin Seipp wrote: > >Excerpts from Andrew Coppin's message of Sat Nov 29 03:37:58 -0600 2008: > > > >>Are you seriously asserting that it's "bad" for people to stop and think > >>about their designs before building? > > > >To be fair, I don't think you're in a position to say whether the > >authors of these libraries took careful consideration in their design > >or not; unless, of course, you wrote one of them and *didn't* think > >about the design? > > I said "I think we should take a step back and work out a plan" and Don > said "no, I think we should just keep blindly hacking away instead". So > I said that seems like a very bad idea to me... I didn't say that - you just made it up! And you even added fake quotes! Andrew, seriously, it's about time you contributed some code, rather than just empty noise on the list? -- Don From bulat.ziganshin at gmail.com Sat Nov 29 15:02:21 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Nov 29 14:56:23 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <493188A1.4020906@btinternet.com> References: <9979e72e0811291008j4e4c126dm787da404da3a70@mail.gmail.com> <493188A1.4020906@btinternet.com> Message-ID: <384702059.20081129230221@gmail.com> Hello Andrew, Saturday, November 29, 2008, 9:23:29 PM, you wrote: > This goes beyond array libraries; do you have any idea how many "binary" > packages there are? i wrote 3 :))) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From kili at outback.escape.de Sat Nov 29 15:16:51 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Sat Nov 29 15:13:47 2008 Subject: [Haskell-cafe] Cabal (was: Compilers) In-Reply-To: <20081129193152.GA30959@scytale.galois.com> References: <20081124042513.GA23604@scytale.galois.com> <492DBE9E.70701@btinternet.com> <492DC605.4030602@btinternet.com> <62A837ED-079C-4E15-8863-75AFCDA4BF28@cs.otago.ac.nz> <20081129033017.GB31753@sliver.repetae.net> <20081129113039.GA29053@petunia.outback.escape.de> <20081129193152.GA30959@scytale.galois.com> Message-ID: <20081129201651.GA8079@petunia.outback.escape.de> On Sat, Nov 29, 2008 at 11:31:52AM -0800, Don Stewart wrote: > > I don't see any advantage in Cabal, except that a .cabal file > > provides some metadata and dependency information that can help the > > build. > > And we have tools to automate the packaging of cabal-specified code. > So for example, there are already native packages of LHC, but not of > JHC. > > http://aur.archlinux.org/packages.php?ID=21749 > > Because of the automatic packaging for cabal-specified software. Oh, maybe I'll write similar tools for OpenBSD ports some day (when I've enough time). Yet I consider this (useful) configuration and dependency information metadata. IMHO, Cabal is nice for specifying this metadata, it maybe nice wrt hackage, some people even may like to just cabal-install something and go ahead, but this are already too much tasks it's trying to fulfill, leaving alone Cabal as a *build* tool. I'm probably biased, because I had so much trouble with ghc and the Cabal/make maze, so I may be a little bit unfair (because ghc's requirements are more complicated than just an ordinary program or library). However, I really believe in the unix philosophy (one tool for one task), and Cabal clearly doesn't follow it. There's an example for a tool capable of dependency and (to a certain degree) configuration management in the java world: ivy (http://ant.apache.org/ivy/). Well, they added a lot of bload since they moved to apache, and of course one could question why everything has to be XML, but the basic idea was: deal with dependencies, add support for repositories containing dependencies in several versions, but nothing more. No build tool, no packaging or install tool. Yes, it's tightly coupled with apache-ant, but if you have an ivy-file, there's nothing stopping you from converting the information contained in this file to some includable makefile snippet. I didn't have a very close look at the ghc-new-build-system yet, but I think the idea here is basically the same: use the .cabal files (and the Cabal library) to generate files that then are used by make(1) to do the real work. I hope that I make at least a little bit sense. The problem I've with Cabal is that it tries to be the swiss army knife of dependency and configuration management, building, packaging and installation, but like those swiss army knifes on steroids (with too much features), it doesn't fit in you pocket any longer. Ciao, Kili From andrewcoppin at btinternet.com Sat Nov 29 16:32:51 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Nov 29 16:26:20 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <4931A971.8050207@henning-thielemann.de> References: <9979e72e0811291008j4e4c126dm787da404da3a70@mail.gmail.com> <493188A1.4020906@btinternet.com> <4931A971.8050207@henning-thielemann.de> Message-ID: <4931B503.7070108@btinternet.com> Henning Thielemann wrote: > I suspect that this particular function is less useful than you think. > It safes one allocation and might be faster since it uses less cache, > but on the other hand, it cannot be fused. If the array is "seriously large", you don't want to have five or six versions of it sitting in memory until the GC comes along to remove it. (OTOH, presumably an unboxed array can be allocated or freed quite quickly...) At a minimum, you've going to end up with two copies in memory - the existing one, and the one being built. > I think in-place array > updates are only sensible for writing array elements in really random > order. As long as you can formulate your algorithm the way "read from > random indices, but write a complete array from left to right", there is > almost no need for mutable arrays. > Does quick-sort fit that pattern? (I'm guessing yes, since all you need to do is filtering and merging...) Yeah, generally you only need arrays if you really want random access. Except in Haskell, where an array also happens to be the only way of storing large numbers of values unboxed. So sometimes you'll use an array because you want to save space. (E.g., parsing text is usually a sequential process with no random access, but you probably want to use ByteString all the same!) I sometimes also use unboxed arrays for the increase in strictness. I guess the thing to do would be to measure the difference... From dominic.steinitz at blueyonder.co.uk Sat Nov 29 16:56:44 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat Nov 29 17:01:49 2008 Subject: [Haskell-cafe] Control.Exception Funny In-Reply-To: <6339B42E0F6F4B3B9F43E6287BC46DC1@cr3lt> References: <49310C2C.20505@blueyonder.co.uk> <6339B42E0F6F4B3B9F43E6287BC46DC1@cr3lt> Message-ID: <4931BA9C.1000601@blueyonder.co.uk> Claus Reinke wrote: > btw, if your handler cannot return the same type as your action, is this > the right place to catch the exceptions? > That was an example, the real code looks something like this: > do d <- getCurrentDirectory > t <- getCurrentTime > let u = "asn1c." ++ show (utctDay t) ++ "." ++ show (utctDayTime t) > createDirectory u > setCurrentDirectory u > CE.catch (do writeASN1AndC (genFile <.> "asn1") (genFile <.> "c") ty val > runCommands [(asn1c ++ " " ++ asn1cOptions ++ " " ++ skeletons ++ " " ++ (genFile <.> "asn1"), "Failure in asn1c")] > d <- getCurrentDirectory > fs <- getDirectoryContents d > let cFiles = > case os of > "mingw32" -> > (genFile <.> "c"):(name <.> "c"):(cFiles' ["converter-sample.c"] ".c.lnk" fs) > _ -> > (genFile <.> "c"):(name <.> "c"):(cFiles' [genFile <.> "c", name <.> "c", "converter-sample" <.> "c"] ".c" fs) > putStrLn (show cFiles) > putStrLn (show (map compile cFiles)) > runCommands (map compile cFiles) > putStrLn (linker ++ " " ++ linkerOut genFile ++ " " ++ ("*" <.> objectSuffix)) > runCommands [ > (linker ++ " " ++ linkerOut genFile ++ " " ++ ("*" <.> objectSuffix), "Failure linking"), > ((executable genFile) ++ " " ++ (genFile <.> "per"), "Failure executing") > ] > readGen (genFile <.> "per") ty) > (\e -> hPutStrLn stderr ("Problem with generating / compiling\n" ++ show e)) > setCurrentDirectory d Your suggestion: > you'll see 'IOException' listed, so 'show (e::IOException)' might do > what you want. works perfectly. Thanks very much, Dominic. From dav.vire+haskell at gmail.com Sat Nov 29 17:12:36 2008 From: dav.vire+haskell at gmail.com (david48) Date: Sat Nov 29 17:06:09 2008 Subject: [Haskell-cafe] Re: [Haskell] ANN: "Real World Haskell", now shipping In-Reply-To: <20081126171134.GC18426@scytale.galois.com> References: <20081126171134.GC18426@scytale.galois.com> Message-ID: <4c88418c0811291412n5c30bbcar375234843603e50c@mail.gmail.com> On Wed, Nov 26, 2008 at 6:11 PM, Don Stewart wrote: > I'd love it if people took a photo of the book arriving. > With enough photos , I could put together a gallery of Haskell around > the world :-) Will do ! From daniel.is.fischer at web.de Sat Nov 29 17:41:03 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Nov 29 17:32:14 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <20081129104132.GC31753@sliver.repetae.net> References: <20081124042513.GA23604@scytale.galois.com> <20081129034142.GR27887@scytale.galois.com> <20081129104132.GC31753@sliver.repetae.net> Message-ID: <200811292341.04247.daniel.is.fischer@web.de> Am Samstag, 29. November 2008 11:41 schrieb John Meacham: > On Fri, Nov 28, 2008 at 07:41:42PM -0800, Don Stewart wrote: > > john: > > > On Wed, Nov 26, 2008 at 07:20:12PM -0800, Jason Dagit wrote: > > > > I spoke with the author of the fork a bit in IRC around the time it > > > > happened and my understanding is that: > > > > 1) John sternly objects to using cabal as the build system for JHC > > > > > > This is a fairly silly reason to fork a project, especially jhc, for a > > > number of reasons. > > > > One of the reasons though, for the branching, is that the potential > > developers, who all have Haskell toolchains, couldn't do: > > > > $ cabal install jhc > > > > Then now can, but have to write 'lhc' instead of 'jhc'. > > > > We've probably just increased the jhc "alpha user" base 10 fold. Hooray! Yes, that's very nice to be able to just type $ cabal update $ cabal install whatever and cabal automatically takes care of dependencies (unfortunately only Haskell dependencies, but hey, can't expect real magic), while the configure && make build system requires me to do it all myself (which becomes a real PITA when there are many dependencies not yet installed). > > Also, I am not so sure who these people are who are willing to type 10 > characters to try out jhc, but not a dozen more. I doubt a few dozen keystrokes make a difference to those who are willing to try out jhc, but chasing dependencies could make a difference. Fortunately jhc hasn't many, so I was ready to try both methods. 1. cabal install lhc 20 minutes later I have an lhc executable installed (and the graphviz package), great, can't be any simpler. Unfortunately: $ lhc -o lhcHeap heapMain lhc: user error (LibraryMap: Library base not found!) Oops. 2. grab jhc, configure && make I need ghc >= 6.8.2, yes, 6.8.3 DrIFT, yes, 2.2.3 binary, yes zlib, yes Great, nothing I don't already have, so download the source tarball, unpack and ./configure --prefix=$HOME checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes ... more configure output ... checking for drift-ghc... no configure: error: DrIFT not found get it from http://repetae.net/computer/haskell/DrIFT/ Huh? dafis@linux:~/jhc/jhc-0.5.20080307> which DrIFT /home/dafis/.cabal/bin/DrIFT dafis@linux:~/jhc/jhc-0.5.20080307> DrIFT --version Version DrIFT-2.2.3 Okay, ./configure --help and searching through the configure script (which I completely don't know the syntax of) lead me to try ./configure --prefix=$HOME DRIFTGHC=/home/dafis/.cabal/bin/DrIFT which successsfully completes the configure step, but shouldn't configure find executables in the path? Now make. Lots of warnings, but doesn't fail. make install, okay, ready to go. helloWorld works, good, but dumps thousands of lines of output I don't want. How do I tell jhc to shut up, and why isn't that the default? Now something a bit harder, make me a couple of primes. First problem: import System.Environment (getArgs) Error: Module not found: System.Environment Okay, different organisation of base package, mildly annoying, use import System (getArgs). Now ... myriads of lines of output ... jhc: user error (Grin.FromE - Unknown primitive: ("eqRef__",[EVar (6666::ELit (Data.IORef.Ref__ (ELit (Jhc@.Box.*::ESort *))::ESort #)),EVar (6670::ELit (Data.IORef.Ref__ (ELit (Jhc@.Box.*::ESort *))::ESort #))])) What? And I get the same error for every nontrivial programme I tried to compile, but not for a couple of trivial programmes. So I spent a few of hours to litter my hard disk with a completely useless broken lhc and a basically useless broken jhc :( Conclusion: the cabal package is much easier to install, but in this case the result of configure && make is marginally more useful. However, neither produced a working compiler, so no cake. Both systems suck when they fail. Cheers, Daniel From bulat.ziganshin at gmail.com Sat Nov 29 17:58:00 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Nov 29 17:52:01 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <200811292341.04247.daniel.is.fischer@web.de> References: <20081124042513.GA23604@scytale.galois.com> <20081129034142.GR27887@scytale.galois.com> <20081129104132.GC31753@sliver.repetae.net> <200811292341.04247.daniel.is.fischer@web.de> Message-ID: <10510627621.20081130015800@gmail.com> Hello Daniel, Sunday, November 30, 2008, 1:41:03 AM, you wrote: > Yes, that's very nice to be able to just type > $ cabal update > $ cabal install whatever > and cabal automatically takes care of dependencies (unfortunately only Haskell i have to mention that there are no haskell compilers that work this way. may be this say something important about Cabal? ;) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From mad.one at gmail.com Sat Nov 29 18:17:57 2008 From: mad.one at gmail.com (Austin Seipp) Date: Sat Nov 29 18:11:33 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <200811292341.04247.daniel.is.fischer@web.de> References: <20081124042513.GA23604@scytale.galois.com> <20081129034142.GR27887@scytale.galois.com> <20081129104132.GC31753@sliver.repetae.net> <200811292341.04247.daniel.is.fischer@web.de> Message-ID: <1227999435-sup-993@existential.local> Hi Daniel, > 1. cabal install lhc > 20 minutes later I have an lhc executable installed (and the graphviz > package), great, can't be any simpler. Awesome! Glad it worked for you. A tidbit: unfortunately, due to a mistake in the first upload of lhc, you will need to provide an exact version if you want the latest and greatest. The reason behind this is because when David uploaded lhc initially, he gave it a version of '20081121'. After a few days of hacking the source code, I decided to upload a new version - but I changed the version number to 0.6.20081127 (it is 0.6 because jhc is currently at 0.5, and I see the improvements we made as worthy of a minor version bump.) So, as far as cabal is concerned, 20081121 > 0.6.20081127, so it will by default install the older version. If you would be so kind as to try the latest lhc instead by running: $ cabal install lhc-0.6.20081127 And reporting back, I would like to hear the results and if it went well. :) > Unfortunately: > $ lhc -o lhcHeap heapMain > lhc: user error (LibraryMap: Library base not found!) > > Oops. There is a reason this is happening, and there isn't an easy way to get around it right now, it seems. The problem is that when you just install lhc, it has no libraries. To install the base library, you are going to need a copy of the lhc source code - this cannot be automated by hackage. Why? Because we are afraid that by uploading lhc's version of base - simply called 'base' - to hackage, will will inadvertantly stop every continually uploaded package from building, and cabal install could stop working too. Scary thought, huh? :) The easiest way to fix this problem is by doing the following: 1. You probably want the darcs version of LHC anyway if you're willing to try it. Good improvements are being made pretty much every day. 2. After you get the darcs repository, just go into it and do 'cabal install' 3. To install base, you are probably going to want the latest versions of both cabal and cabal-install from the darcs repository - they include support for LHC already (cabal 1.7.x.) 4. After you've installed lhc and the latest cabal/cabal install, you can just do: $ cd lhc/lib/base $ cabal install --lhc And it should Just Work. All of these instructions can be found here: http://lhc.seize.it/#development Don Stewart just brought up this point in #haskell, so I think I will modify the wiki page a bit (http://lhc.seize.it) and highlight these notes and why it's currently like this. I apologize for it being so cumbersome right now. We're trying to figure out a good solution. > Okay, ./configure --help and searching through the configure script (which I > completely don't know the syntax of) lead me to try > ./configure --prefix=$HOME DRIFTGHC=/home/dafis/.cabal/bin/DrIFT > which successsfully completes the configure step, but shouldn't configure find > executables in the path? The reason is because the configure.ac script is designed to search for an executable named 'drift-ghc', not 'DrIFT'. I have no idea why. > import System (getArgs). Now > ... myriads of lines of output ... > jhc: user error (Grin.FromE - Unknown primitive: ("eqRef__",[EVar (6666::ELit > (Data.IORef.Ref__ (ELit (Jhc@.Box.*::ESort *))::ESort #)),EVar (6670::ELit > (Data.IORef.Ref__ (ELit (Jhc@.Box.*::ESort *))::ESort #))])) > > What? > And I get the same error for every nontrivial programme I tried to compile, > but not for a couple of trivial programmes. LHC and JHC are still extremely incomplete. They're nowhere near as supportive of extensions or libraries as GHC is. Don't count on them compiling anything non-trivial just yet. Austin From dons at galois.com Sat Nov 29 18:19:03 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 29 18:12:32 2008 Subject: [Haskell-cafe] Compilers In-Reply-To: <10510627621.20081130015800@gmail.com> References: <20081124042513.GA23604@scytale.galois.com> <20081129034142.GR27887@scytale.galois.com> <20081129104132.GC31753@sliver.repetae.net> <200811292341.04247.daniel.is.fischer@web.de> <10510627621.20081130015800@gmail.com> Message-ID: <20081129231903.GA31597@scytale.galois.com> bulat.ziganshin: > Hello Daniel, > > Sunday, November 30, 2008, 1:41:03 AM, you wrote: > > > Yes, that's very nice to be able to just type > > $ cabal update > > $ cabal install whatever > > and cabal automatically takes care of dependencies (unfortunately only Haskell > > i have to mention that there are no haskell compilers that work this > way. may be this say something important about Cabal? ;) Though there's a perl compiler, $ cabal install pugs Enjoy! -- Don (who thinks we need less talk, more action) From sebastian.sylvan at gmail.com Sat Nov 29 18:43:59 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Sat Nov 29 18:37:32 2008 Subject: [Haskell-cafe] Data parallelism doesn't seem to work on windows... Message-ID: <3d96ac180811291543j6270a45co39298905d4ff046c@mail.gmail.com> Hi,I can't seem to get DPH to work on 6.10.1 on Vista-64. I run the executables with +RTS -N2, and to verify that I'm doing it correctly I checked with a simple benchmark using forkIO and that does indeed use both my cores: -- compiler command line: ghc --make -O2 -threaded parr.hs -- execution command line: parr.exe +RTS -N2 main = do forkIO $ print [ True | n <- [ 1000 .. 3000], fac n == 0 ] forkIO $ print [ True | n <- [ 1000 .. 3000], fac n == 0 ] getLine return () This, on the other hand does not use more than one core: -- compiler command line (from shootout code): ghc --make -fcpr-off -threaded -fdph-par -package dph-base -Odph -XPArr parr2.hs -- execution as before main = print $ [: True | n <- [: 1000 .. 5000 :], fac n == 0 :] That's 4000 items of work there, so surely it should kick off plenty of sparks to overcome the "sparks bug"? -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081129/8ebce78a/attachment.htm From rl at cse.unsw.edu.au Sat Nov 29 18:58:01 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Sat Nov 29 18:51:45 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: References: <9cc3782b0811111349g2db9b16ai6cce39757155ba50@mail.gmail.com> <492EAC58.5080207@gmail.com> <718AAA7EDD8244709E670ACE86B80C29@cr3lt> <7CB8E5D9-5EDC-49BE-BD8F-BBFFDFA5E380@cse.unsw.edu.au> <492FB41B.6000700@gmail.com> <493065FE.2090003@btinternet.com> <20081128214611.GD27887@scytale.galois.com> <3CFC2F81637043999463748C4C8A0B88@cr3lt> <024D3792-3FF7-43AC-AD89-281D26AF958F@cse.unsw.edu.au> Message-ID: On 30/11/2008, at 02:43, Brad Larsen wrote: > On Fri, 28 Nov 2008 19:00:38 -0500, Roman Leshchinskiy > wrote: > >> On 29/11/2008, at 10:47, Claus Reinke wrote: > [...] >>> And would it be difficult for you all to agree on a standard API, to >>> make switching between the alternatives easy (if >>> it is indeed impossible to unify their advantages in a single >>> library, >>> the reasons for which should also be documented somewhere)? >> >> Yes, it is very difficult. A sensible API for a standard array >> library >> is something that needs more research. FWIW, I don't know of any >> other >> language that has what I'd like to see in Haskell. C++ probably comes >> closest but they have it easy - they don't do fusion. > [...] > > Would you elaborate on what you'd like to see in an array library? I'd like to have a library which is efficient (in particular, implements aggressive fusion), is roughly equivalent to the current standard list library in power and supports strict/unboxed/mutable arrays. It should also provide a generic framework for implementing new kinds of arrays. And eventually, it should also be usable in high- performance and parallel algorithms. > And perhaps which C++ array library you are thinking of? Your C++ > comment caught my attention, and now I'm curious. Surely you don't > mean C-style arrays. :-D No, I meant vector, basic_string and deque which are provided by the standard library. Roman From rl at cse.unsw.edu.au Sat Nov 29 19:03:00 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Sat Nov 29 18:56:42 2008 Subject: [Haskell-cafe] Data parallelism doesn't seem to work on windows... In-Reply-To: <3d96ac180811291543j6270a45co39298905d4ff046c@mail.gmail.com> References: <3d96ac180811291543j6270a45co39298905d4ff046c@mail.gmail.com> Message-ID: <600DAFC4-63D0-44BF-97AA-A9A91D709243@cse.unsw.edu.au> On 30/11/2008, at 10:43, Sebastian Sylvan wrote: > This, on the other hand does not use more than one core: > > -- compiler command line (from shootout code): ghc --make -fcpr-off - > threaded -fdph-par -package dph-base -Odph -XPArr parr2.hs > -- execution as before > main = print $ [: True | n <- [: 1000 .. 5000 :], fac n == 0 :] Unfortunately, that's not enough to get parallelism. You also need to - fvectorise the computation, i.e., everything that comes after $ (but not print because that can't be vectorised yet). At the moment, this means that you have to split your code in two modules because - fvectorise is a module-wide flag. Please take a look at dph/examples/ dotp to see how this is done. Sorry that this is so inconvenient at the moment but we're working on it! Roman From rl at cse.unsw.edu.au Sat Nov 29 19:30:06 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Sat Nov 29 19:24:01 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <4931B503.7070108@btinternet.com> References: <9979e72e0811291008j4e4c126dm787da404da3a70@mail.gmail.com> <493188A1.4020906@btinternet.com> <4931A971.8050207@henning-thielemann.de> <4931B503.7070108@btinternet.com> Message-ID: <13360B27-A90A-4B23-8042-662ACBDC1434@cse.unsw.edu.au> On 30/11/2008, at 08:32, Andrew Coppin wrote: > Henning Thielemann wrote: >> I suspect that this particular function is less useful than you >> think. >> It safes one allocation and might be faster since it uses less cache, >> but on the other hand, it cannot be fused. Hmm, I haven't seen your original message but I suspect you are talking about in-place map. In that case, this is not entirely true. Shameless plug: http://www.cse.unsw.edu.au/~rl/publications/recycling.html >> I think in-place array >> updates are only sensible for writing array elements in really random >> order. As long as you can formulate your algorithm the way "read from >> random indices, but write a complete array from left to right", >> there is >> almost no need for mutable arrays. Many array algorithms cannot really be written in this way. I think we do need mutable arrays and they should provide much more than just read/write. How to integrate them nicely with immutable arrays is not really clear, though. Roman From dons at galois.com Sat Nov 29 19:36:50 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 29 19:30:23 2008 Subject: [Haskell-cafe] Re: Go Haskell! -> array libraries In-Reply-To: <13360B27-A90A-4B23-8042-662ACBDC1434@cse.unsw.edu.au> References: <9979e72e0811291008j4e4c126dm787da404da3a70@mail.gmail.com> <493188A1.4020906@btinternet.com> <4931A971.8050207@henning-thielemann.de> <4931B503.7070108@btinternet.com> <13360B27-A90A-4B23-8042-662ACBDC1434@cse.unsw.edu.au> Message-ID: <20081130003650.GA31734@scytale.galois.com> rl: > On 30/11/2008, at 08:32, Andrew Coppin wrote: > > >Henning Thielemann wrote: > >>I suspect that this particular function is less useful than you > >>think. > >>It safes one allocation and might be faster since it uses less cache, > >>but on the other hand, it cannot be fused. > > Hmm, I haven't seen your original message but I suspect you are > talking about in-place map. In that case, this is not entirely true. > Shameless plug: > > http://www.cse.unsw.edu.au/~rl/publications/recycling.html > > >>I think in-place array > >>updates are only sensible for writing array elements in really random > >>order. As long as you can formulate your algorithm the way "read from > >>random indices, but write a complete array from left to right", > >>there is > >>almost no need for mutable arrays. > > Many array algorithms cannot really be written in this way. I think we > do need mutable arrays and they should provide much more than just > read/write. How to integrate them nicely with immutable arrays is not > really clear, though. Should mutable arrays have list-like APIs? All the usual operations, just in-place and destructive where appropriate? -- Don From john at repetae.net Sat Nov 29 20:02:31 2008 From: