From alfonso.acosta at gmail.com Wed Oct 1 07:29:38 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Wed Oct 1 07:26:19 2008 Subject: [Haskell] ANN: Haskell-Embedded System Design: ForSyDe 3.0 and Tutorial Message-ID: <6a7c66fc0810010429na4e5981ld5a71d2ff832e9a@mail.gmail.com> Hi everyone, I am glad to announce the 3.0 release of ForSyDe's implementation, now available from HackageDB. The ForSyDe (Formal System Design) methodology has been developed with the objective to move system design (e.g. System on Chip, Hardware and Software systems) to a higher level of abstraction. ForSyDe is implemented as a Haskell-embedded behavioral DSL (Domain Specific Language). >From this release, ForSyDe includes a new deep-embedded DSL and embedded compiler. We have also published tutorial which should be much more user-friendly than the Haddock documentation and the ForSyDe research papers. ForSyDe includes two DSL flavours which offer different features: 1) Deep-embedded DSL (ForSyDe.Signal) Deep-embedded signals, based on the same concepts as Lava, are aware of the system structure. Based on that structural information ForSyDe's embedded compiler, can perform different analysis and transformations. o Thanks to Template Haskell, computations are expressed in Haskell, not needing to specifically design a DSL for that purpose. o Embedded compiler backends: + Simulation + VHDL (with support for Modelsim and Quartus II) + GraphML (with yFiles graphical markup support.) o Synchronous model of computation. o Support for components. o Support for fixed-sized vectors ? la VHDL. 2) Shallow-embedded DSL (ForSyDe.Shallow.Signal) Shallow-embedded signals are modeled as streams of data isomorphic to lists. Systems built with them are unfortunately restricted to simulation, however, shallow-embedded signals provide a rapid-prototyping framework with which to experiment with Models of Computation (MoCs). o Synchronous MoC. o Untimed MoC. o Continuous Time MoC. o Domain Interfaces allow connecting various subsystems with different timing (domains) regardless of their MoC. o Deep-embedded models can be integrated through simulation. Links ==== ForSyDe website: http://www.ict.kth.se/org/ict/ecs/sam/projects/forsyde/www/ ForSyDe tutorial: http://www.ict.kth.se/org/ict/ecs/sam/projects/forsyde/www/files/tutorial/tutorial.html HackageDB package page: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ForSyDe Darcs repository: darcs get http://www.ict.kth.se/org/ict/ecs/sam/projects/forsyde/www/darcs/ForSyDe/ From dons at galois.com Wed Oct 1 13:38:50 2008 From: dons at galois.com (Don Stewart) Date: Wed Oct 1 13:35:25 2008 Subject: [Haskell] ANN: Haskell-Embedded System Design: ForSyDe 3.0 and Tutorial In-Reply-To: <6a7c66fc0810010429na4e5981ld5a71d2ff832e9a@mail.gmail.com> References: <6a7c66fc0810010429na4e5981ld5a71d2ff832e9a@mail.gmail.com> Message-ID: <20081001173850.GC32701@scytale.galois.com> alfonso.acosta: > Hi everyone, > > I am glad to announce the 3.0 release of ForSyDe's implementation, now > available from HackageDB. > Awesome, native packages now available, http://aur.archlinux.org/packages.php?ID=20422 -- Don From amal.j.ahmed at gmail.com Wed Oct 1 16:00:49 2008 From: amal.j.ahmed at gmail.com (Amal Ahmed) Date: Wed Oct 1 15:57:29 2008 Subject: [Haskell] TLDI 2009: call for papers Message-ID: <666bd19b0810011300g1e54a3dfs87e9fb2bc709c136@mail.gmail.com> [Just a quick reminder that the TLDI deadline is Oct 8th...] ********************************************************************* CALL FOR PAPERS TLDI 2009 ACM SIGPLAN Workshop on Types in Language Design and Implementation 24 January 2009 Savannah, Georgia, USA To be held in conjunction with POPL 2009 http://ttic.uchicago.edu/~amal/tldi2009/ ********************************************************************* IMPORTANT DATES Submission: 8 Oct 2008, 5PM EDT (Wed) Notification: 8 Nov 2008 (Sat) Camera ready: 19 Nov 2008 (Wed) TLDI'09: 24 January 2009 (Sat) SCOPE The role of types and proofs in all aspects of language design, compiler construction, and software development has expanded greatly in recent years. Type systems, type analyses, and formal deduction have led to new concepts in compilation techniques for modern programming languages, verification of safety and security properties of programs, program transformation and optimization, and many other areas. In light of this expanding role of types, the ACM SIGPLAN Workshop on Types in Language Design and Implementation (TLDI'09) follows six previous International Workshops on types in compilation and language design (TIC'97, TIC'98, TIC'00, TLDI'03, TLDI'05, and TLDI'07), with the hope of bringing together researchers to share new ideas and results in this area. Submissions for this event are invited on all interactions of types with language design, implementation, and programming methodology. This includes both practical applications and theoretical aspects. TLDI'09 specifically encourages papers from a broad field of programming language and compiler researchers, including those working in object-oriented, dynamically-typed, late-binding, systems programming, and mobile-code paradigms, as well as traditional fully-static type systems. Topics of interest include: - Typed intermediate languages and type-directed compilation - Type-based language support for safety and security - Types for interoperability - Type systems for system programming languages - Type-based program analysis, transformation, and optimization - Dependent types and type-based proof assistants - Types for security protocols, concurrency, and distributed computing - Type inference and type reconstruction - Type-based specifications of data structures and program invariants - Type-based memory management - Proof-carrying code and certifying compilation This is not meant to be an exhaustive list; papers on novel utilizations of type information are welcome. Authors concerned about the suitability of a topic are encouraged to inquire via electronic mail to the program chair prior to submission. SUBMISSION GUIDELINES Authors should submit a full paper of no more than 12 pages (including bibliography and appendices) by Wednesday, October 8, 2008 5PM Eastern Daylight Savings Time. The submission deadline and length limitations are firm. Submissions that do not meet these guidelines will not be considered. All submissions should be in standard ACM SIGPLAN conference format: two columns, nine-point font on a ten-point baseline. Detailed formatting guidelines are available on the SIGPLAN Author Information page, along with a LaTeX class file and template: http://www.sigplan.org/authorInformation.htm Papers must be submitted in Adobe Portable Document Format (PDF) and must be formatted for US Letter size (8.5"x11") paper. Authors for whom this is a hardship should contact the program chair before the deadline. Submitted papers must adhere to the SIGPLAN Republication Policy: http://www.sigplan.org/republicationpolicy.htm Submissions should contain original research not published or submitted for publication elsewhere. The URL for submission will be announced closer to the deadline. GENERAL CHAIR Andrew Kennedy Microsoft Research, Cambridge PROGRAM CHAIR Amal Ahmed Toyota Technological Institute, Chicago PROGRAM COMMITTEE Amal Ahmed Toyota Technological Institute, Chicago (Chair) Juan Chen Microsoft Research Peter Dybjer Chalmers University of Technology Jeff Foster University of Maryland, College Park Neal Glew Intel Robert Harper Carnegie Mellon University Andrew Myers Cornell University Atsushi Ohori Tohoku University Matthew Parkinson University of Cambridge Didier Remy INRIA Paris-Rocquencourt Andreas Rossberg Max Planck Institute for Software Systems STEERING COMMITTEE Craig Chambers University of Washington Robert Harper Carnegie Mellon University (Chair) Xavier Leroy INRIA Paris-Rocquencourt Greg Morrisett Harvard University George Necula Rinera Networks and UC Berkeley Atsushi Ohori Tohoku University Francois Pottier INRIA Paris-Rocquencourt Zhong Shao Yale University -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20081001/cee3589b/attachment.htm From byorgey at seas.upenn.edu Wed Oct 1 22:17:09 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Wed Oct 1 22:13:52 2008 Subject: [Haskell] Haskell Weekly News: Issue 87 - October 1, 2008 Message-ID: <20081002021709.GA31623@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20081001 Issue 87 - October 01, 2008 --------------------------------------------------------------------------- Welcome to issue 87 of HWN, a newsletter covering developments in the [1]Haskell community. ICFP was held last week in Victoria, and by all accounts was a great success! This edition of the HWN includes much ICFP and Haskell Symposium-related content, including [2]videos of the Haskell symposium presentations, [3]programming contest results, some [4]notes on the future of Haskell, and slides from [5]a Haskell tutorial and [6]a talk about the Haskell Platform. But ICFP didn't seem to slow down the community all that much: you'll find the usual mix of newly released and updated packages, blog posts, mailing list discussions, and silly quotes as well. Announcements Haskell-Embedded System Design: ForSyDe 3.0 and Tutorial. Alfonso Acosta [7]announced the [8]3.0 release of [9]ForSyDe. The ForSyDe (Formal System Design) methodology has been developed with the objective to move system design (e.g. System on Chip, Hardware and Software systems) to a higher level of abstraction. ForSyDe is implemented as a Haskell-embedded behavioral DSL (Domain Specific Language). The 3.0 release includes a new deep-embedded DSL and embedded compiler, as well as a new user-friendly tutorial. Graphalyze-0.1. Ivan Miljenovic [10]announced the initial release of his graph-theoretic analysis library, [11]Graphalyze. This is a pre-release of the library he is writing for his mathematics honours thesis, "Graph-Theoretic Analysis of the Relationships in Discrete Data". Symposium videos. Malcolm Wallace [12]announced [13]guerrilla videos of the Haskell Symposium 2008 presentations. ICFP programming contest results. Malcolm Wallace [14]sent a link to [15]a video of the ICFP programming contest results presentation. Version 0.4.3 of happs-tutorial is a HAppS job board, done in HAppS.. Thomas Hartman [16]announced version 4 of the [17]self-demoing HAppS tutorial, a HAppS job board. TH code for deriving Binary and NFData instances. Tim Newsham [18]announced some [19]Template Haskell code for automatically deriving Data.Binary and Control.Parallel.Strategies.NFData instances. Notes on the future of Haskell from ICFP. Bryan O'Sullivan [20]posted a [21]writeup from the ICFP conference floor on the future of Haskell and functional programming. datapacker 1.0.1. John Goerzen [22]announced the [23]release of datapacker 1.0.1. A Functional Implementation of the Garsia-Wachs Algorithm. Nicolas Pouillard [24]announced a [25]Haskell implementation of an algorithm that builds a binary tree with minimum weighted path length from weighted leaf nodes given in symmetric order. This can be used to build optimum search tables, to balance a 'ropes' data structure in an optimal way. graphviz-2008.9.20. Ivan Miljenovic [26]announced a new version of [27]Matthew Sackman's Haskell bindings to Graphviz. See Ivan's original announcement for information on what new features are included, and what the difference is among the various graphviz-related packages on Hackage. darcs 2.1.0pre2. Eric Kow [28]announced the release of darcs 2.1.0pre2, formerly known as 2.0.3. See Eric's announcement for a list of new features and bug fixes in this release. protocol-buffers-0.2.9 for Haskell is ready. ChrisK [29]announced the release of the [30]protocol-buffers package, which generates Haskell data types that can be converted back and forth to lazy ByteStrings that interoperate with Google's generated code in C++/Java/python. panda blog engine. Jinjing Wang [31]announced the release of [32]panda, a simple blog engine written in Haskell. OpenSPARC project applicant chosen. Duncan Coutts [33]announced that Ben Lippmeier has been chosen for the [34]OpenSPARC project. Ben will spend three months hacking on GHC to make it perform well on the latest multi-core OpenSPARC chips. Hugs on the iPhone. Alberto Galdo [35]announced that he has gotten Hugs to run on the iPhone, and has made packages available for others who would like to install it as well. Discussion Shooting yourself in the foot in Haskell. John Van Enk [36]asked how to shoot yourself in the foot with Haskell, with humorous results. Total Functional Programming in Haskell. Jason Dagit started a [37]discussion on total functional programming, Haskell, abstraction boundaries and the IO monad, and related topics. Health effects. Andrew Coppin told a [38]story about a chocolate bar and recursion, which led to a discussion of optimization problems, Dedekind cuts, some meta-discussion of the discussion, and entirely too many puns. The container problem. Andrew Coppin [39]asked about the possibility if abstracting over various sorts of containers in Haskell, and why there isn't a widely used library that does this. A discussion of various container libraries and the language issues that arise followed. Red-Blue Stack. Matthew Eastman [40]asked how to implement a certain data structure (red-blue stacks) in Haskell. Several people responded with increasingly clever solutions, and a comparison of mutating vs. non-mutating algorithms. Climbing up the shootout.... Don Stewart began a long and ongoing [41]discussion about improving Haskell's performance on benchmarks in the [42]Shootout, now that there is a quad core machine for running benchmarks! Line noise. Andrew Coppin started an [43]interesting discussion about perceptions of Haskell syntax by programmers who aren't familiar with it. Jobs London FP job in asset management. Michael Bott [44]announced an opportunity for two functional programmers based in London, with a software house specialising in asset management. Blog noise [45]Haskell news from the [46]blogosphere. * Creighton Hogg: [47]Some first steps with Data.Reactive. Creighton gives some simple examples of using Conal Elliott's Reactive library. More to come! * Bryan O'Sullivan: [48]Unix hacking in Haskell: better pseudoterminal support. * Creighton Hogg: [49]One last thought on laziness. In Creighton's opinion, laziness is the single hardest thing to get used to in Haskell. If you're learning Haskell, don't despair, break out the pencil and paper! * Douglas M. Auclair (geophf): [50]Animal as RDR, part III. * Neil Mitchell: [51]General Updates. * Don Stewart (dons): [52]Newest Mersenne Prime. Haskell doesn't even break a sweat computing the largest known prime number. * Douglas M. Auclair (geophf): [53]Animal as RDR, part II. * Bryan O'Sullivan: [54]Using Bloom filters for large scale gene sequence analysis in Haskell. A paper that Bryan and Ketil Malde submitted to PADL 09. "The Cliff's Notes version: Bloom filters are almost unused in bioinformatics; they're tremendously useful; and our Haskell code is really fast. * >>> Zubin Wadia: [55]Simon Peyton Jones & Microsoft Research Cambridge. Zubin thinks quite highly of SPJ and MSR Cambridge. * Bryan O'Sullivan: [56]Slides from my DEFUN 2008 Haskell tutorial. * Mads Lindstroem: [57]Inheritance in Composites and Overlapping Instances. * >>> Micah Cowan: [58]Adventures in Haskell. Micah shares some thoughts on learning Haskell. * Bryan O'Sullivan: [59]Some notes on the future of Haskell and FP. * Well-Typed.Com: [60]Slides from the Haskell Platform talk. * Paul Johnson: [61]Why the banks collapsed, and how a paper on Haskell programming can help stop it happening next time. * >>> Nathan Sanders: [62]Two weeks of Haskell. Nathan shares some thoughts on his first two weeks learning Haskell. * Bryan O'Sullivan: [63]Twittering from ICFP / Haskell symposium / CUFP. * Real-World Haskell: [64]Slides from ACCU talk. * Eric Kow (kowey): [65]darcs weekly news #5. * John Goerzen (CosmicRay): [66]New version of datapacker. * >>> James Cowie: [67]Haskell, the verdict!. James is impressed with Haskell after using it for a few weeks. * >>> Alex Combas: [68]What's all this fuss about Haskell?. Alex is thinking of learning Haskell in his spare time. * Aaron Tomb: [69]Parsing the Linux kernel with Haskell: experience with Language.C. Aaron is impressed by the new Language.C libraries, which parses all 18 million pre-processed lines of Linux kernel source with no problems! Quotes of the Week * Fuse_: Oh, sorry for hijacking mathematical purity with dirty fiscal dynamical systems. :o * mauke: data Mushroom badger = Mushroom badger badger badger badger badger badger badger badger badger where's the snake deriving Snake * ddarius: higher order of lambdabot deployment and management engineers or HOLDME * Botje: #haskell: parallellising your homework answers! * olsner: most everything gives nicer everything than perl * Botje: fuzzy feelings aren't always aerodynamic, unfortunately. * chrisdone: benchmarks only exist to make fun of ruby * Claus Reinke: [on breaking code up into smaller bits] Once your readers understand your code, you can add the one-liner and ask for applause. * Jake Mcarthur: A fold by any other name would smell as sweet. * lispy: Schroedinger's cat is really in a thunk not a box * Bulat: Haskell was developed with goal to hide implementation details from egg-headed scientists and this obviously should have some drawbacks About the Haskell Weekly News New editions are posted to [70]the Haskell mailing list as well as to [71]the Haskell Sequence and [72]Planet Haskell. [73]RSS is also available, and headlines appear on [74]haskell.org. To help create new editions of this newsletter, please see the information on [75]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [76]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://haskell.org/haskellwiki/Video_presentations/Haskell_Symposium_2008 3. http://video.google.com/videoplay?docid=-4697764813432201693 4. http://www.serpentine.com/blog/2008/09/26/some-notes-on-the-future-of-haskell-and-fp/ 5. http://www.serpentine.com/blog/2008/09/27/slides-from-my-defun-2008-haskell-tutorial/ 6. http://blog.well-typed.com/2008/09/slides-from-the-haskell-platform-talk/ 7. http://article.gmane.org/gmane.comp.lang.haskell.general/16443 8. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ForSyDe 9. http://www.ict.kth.se/org/ict/ecs/sam/projects/forsyde/www/ 10. http://article.gmane.org/gmane.comp.lang.haskell.general/16442 11. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Graphalyze 12. http://article.gmane.org/gmane.comp.lang.haskell.general/16440 13. http://haskell.org/haskellwiki/Video_presentations/Haskell_Symposium_2008 14. http://article.gmane.org/gmane.comp.lang.haskell.general/16438 15. http://video.google.com/videoplay?docid=-4697764813432201693 16. http://article.gmane.org/gmane.comp.lang.haskell.cafe/45332 17. http://happstutorial.com:5001/ 18. http://article.gmane.org/gmane.comp.lang.haskell.cafe/45305 19. http://www.thenewsh.com/~newsham/store/DeriveBinary.hs 20. http://article.gmane.org/gmane.comp.lang.haskell.cafe/45272 21. http://www.serpentine.com/blog/2008/09/26/some-notes-on-the-future-of-haskell-and-fp/ 22. http://article.gmane.org/gmane.comp.lang.haskell.cafe/45185 23. http://changelog.complete.org/posts/760-New-version-of-datapacker.html 24. http://article.gmane.org/gmane.comp.lang.haskell.cafe/45002 25. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/garsia-wachs 26. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44863 27. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/graphviz 28. http://www.haskell.org//pipermail/haskell-cafe/2008-September/048094.html 29. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44845 30. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers 31. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44840 32. http://jinjing.blog.easymic.com/ 33. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44836 34. http://haskell.org/opensparc/ 35. http://www.haskell.org//pipermail/haskell-cafe/2008-September/047838.html 36. http://www.haskell.org//pipermail/haskell-cafe/2008-October/048506.html 37. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/45393 38. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/45370 39. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/45242 40. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/45122 41. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/44916 42. http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all 43. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/44886 44. http://article.gmane.org/gmane.comp.lang.haskell.cafe/45506 45. http://planet.haskell.org/ 46. http://haskell.org/haskellwiki/Blog_articles 47. http://abstractabsurd.blogspot.com/2008/09/some-first-steps-with-datareactive.html 48. http://www.serpentine.com/blog/2008/09/30/unix-hacking-in-haskell-better-pseudoterminal-support/ 49. http://abstractabsurd.blogspot.com/2008/09/one-last-thought-on-laziness.html 50. http://logicaltypes.blogspot.com/2008/09/animal-as-rdr-part-iii.html 51. http://neilmitchell.blogspot.com/2008/09/general-updates.html 52. http://www.cse.unsw.edu.au/~dons/blog/2008/09/30#primes 53. http://logicaltypes.blogspot.com/2008/09/animal-as-rdr-part-ii.html 54. http://www.serpentine.com/blog/2008/09/28/using-bloom-filters-for-large-scale-gene-sequence-analysis-in-haskell/ 55. http://zwadia.com/?p=58 56. http://www.serpentine.com/blog/2008/09/27/slides-from-my-defun-2008-haskell-tutorial/ 57. http://lindstroem.wordpress.com/2008/09/27/inheritance-in-composites-and-overlapping-instances/ 58. http://micah.cowan.name/2008/09/26/computers/software-development/adventures-in-haskell/ 59. http://www.serpentine.com/blog/2008/09/26/some-notes-on-the-future-of-haskell-and-fp/ 60. http://blog.well-typed.com/2008/09/slides-from-the-haskell-platform-talk/ 61. http://paulspontifications.blogspot.com/2008/09/why-banks-collapsed-and-how-paper-on.html 62. http://sandersn.com/blog/index.php?title=two_weeks_of_haskell 63. http://www.serpentine.com/blog/2008/09/25/twittering-from-icfp-haskell-symposium-cufp/ 64. http://www.realworldhaskell.org/blog/2008/09/25/slides-from-accu-talk/ 65. http://koweycode.blogspot.com/2008/09/darcs-weekly-news-5.html 66. http://changelog.complete.org/posts/760-New-version-of-datapacker.html 67. http://www.jcowie.co.uk/2008/09/haskell-the-verdict/ 68. http://combas3d.com/2008/09/whats-all-this-fuss-about-haskell/ 69. http://www.galois.com/blog/2008/09/17/parsing-the-linux-kernel-with-haskell-experience-with-languagec/ 70. http://www.haskell.org/mailman/listinfo/haskell 71. http://sequence.complete.org/ 72. http://planet.haskell.org/ 73. http://sequence.complete.org/node/feed 74. http://haskell.org/ 75. http://haskell.org/haskellwiki/HWN 76. http://code.haskell.org/~byorgey/code/hwn/ From gvidal at dsic.upv.es Fri Oct 3 06:43:11 2008 From: gvidal at dsic.upv.es (German Vidal) Date: Fri Oct 3 06:39:50 2008 Subject: [Haskell] PEPM 2009 - final call for papers Message-ID: F I N A L C A L L F O R P A P E R S === P E P M 2009 === ACM SIGPLAN Workshop on Partial Evaluation and Program Manipulation http://www.clip.dia.fi.upm.es/Conferences/PEPM09 January 19-20, 2009 Savannah, Georgia, USA (Affiliated with POPL 2009) IMPORTANT DATES Abstract due: October 12, 2008 Submission: October 17, 2008 Author Notification: November 10, 2008 Camera-Ready Paper: November 17, 2008 SCOPE The PEPM Symposium/Workshop series aims at bringing together researchers and practitioners working in the areas of program manipulation, partial evaluation, and program generation. PEPM focuses on techniques, theory, tools, and applications of analysis and manipulation of programs. PEPM is classified as category A in the CORE ranking of ICT conferences. The 2009 PEPM workshop will be based on a broad interpretation of semantics-based program manipulation and continue last years' successful effort to expand the scope of PEPM significantly beyond the traditionally covered areas of partial evaluation and specialization and include practical applications of program transformations such as refactoring tools, and practical implementation techniques such as rule-based transformation systems. In addition, the scope of PEPM covers manipulation and transformations of program and system representations such as structural and semantic models that occur in the context of model-driven development. In order to reach out to practitioners, a separate category of tool demonstration papers will be solicited. Topics of interest for PEPM'09 include, but are not limited to: * Program and model manipulation techniques such as transformations driven by rules, patterns, or analyses, partial evaluation, specialization, program inversion, program composition, slicing, symbolic execution, refactoring, aspect weaving, decompilation, and obfuscation. * Program analysis techniques that are used to drive program/model manipulation such as abstract interpretation, static analysis, binding-time analysis, dynamic analysis, constraint solving, and type systems. * Analysis and transformation for programs/models with advanced features such as objects, generics, ownership types, aspects, reflection, XML type systems, component frameworks, and middleware. * Techniques that treat programs/models as data objects including meta-programming, generative programming, staged computation, and model-driven program generation and transformation. * Application of the above techniques including experimental studies, engineering needed for scalability, and benchmarking. Examples of application domains include legacy program understanding and transformation, domain-specific language implementations, scientific computing, middleware frameworks and infrastructure needed for distributed and web-based applications, resource-limited computation, and security. We especially encourage papers that break new ground including descriptions of how program/model manipulation tools can be integrated into realistic software development processes, descriptions of robust tools capable of effectively handling realistic applications, and new areas of application such as rapidly evolving systems, distributed and webbased programming including middleware manipulation, model-driven development, and on-the-fly program adaptation driven by run-time or statistical analysis. SUBMISSION GUIDELINES, CATEGORIES, AND PROCEEDINGS Two submission categories will be considered. Regular Research papers must not exceed 10 pages in ACM Proceedings style. Tool Demonstration papers must not exceed 4 pages in ACM Proceedings style and they should include an appendix of up to 6 additional pages giving an outline, screenshots, examples, etc. to indicate the content of the proposed live demo at the workshop. At least one author of each accepted contribution must attend the workshop and present the work. In the case of tool demonstration papers, a live demonstration of the described tool is expected. Suggested topics, evaluation criteria, and writing guidelines for both research tool demonstration papers is available on the PEPM'09 Web-site. Papers should be submitted electronically via the workshop web site. The workshop proceedings will be published in the ACM Digital Library and hardcopies will be distributed at the workshop. A journal special issue dedicated to PEPM'09 including selected papers is under consideration. PROGRAM CO-CHAIRS German Puebla, Technical University of Madrid, Spain German Vidal, Technical University of Valencia, Spain PEPM 2009 PROGRAM COMMITTEE David Binkley, Loyola College, USA Radhia Cousot, CNRS, France Silvia Crafa, University of Padova, Italy Stephen A. Edwards, Columbia University, USA Lidia Fuentes, University of Malaga, Spain John P. Gallagher, Roskilde University, Denmark Thomas Jensen,IRISA, France Yukiyoshi Kameyama, University of Tsukuba, Japan Siau Cheng Khoo, National University of Singapore Julia Lawall, University of Copenhagen (DIKU), Denmark Shin-Cheng Mu, Academia Sinica, Taiwan Naoki Nishida, Nagoya University, Japan Maurizio Proietti, CNR, Italy Armin Rigo, Switzerland Simon Thompson, Kent University, UK Tarmo Uustalu, Tallinn University of Technology, Estonia Wim Vanhoof, Namur University, Belgium Joost Visser, Software Improvement Group, The Netherlands Janis Voigtlander, TU Dresden, Germany From byorgey at seas.upenn.edu Sat Oct 4 16:35:39 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Oct 4 16:32:11 2008 Subject: [Haskell] Haskell Weekly News: Issue 88 - October 4, 2008 Message-ID: <20081004203539.GA24732@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20081004 Issue 88 - October 04, 2008 --------------------------------------------------------------------------- Welcome to issue 88 of HWN, a newsletter covering developments in the [1]Haskell community. An extra-short HWN this week, so you get an extra ten minutes to do something else during the time you would have normally spent reading the HWN! HWN-editor-approved activities for your ten minutes include eating cookies, playing [2]Fantastic Contraption, and writing a type checker in the type system while eating cookies. Announcements Arch Haskell News: Oct 4 2008. Don Stewart [3]sent out the newest Arch Haskell news --- now with 609 Haskell packages! Announcing OneTuple-0.1.0. John Dorsey [4]announced the release of the ground-breaking [5]OneTuple library, which adds the long neglected one-tuple to Haskell. It also turns out that the denizens of Haskell-cafe are completely unable to refrain from turning jokes into long-winded technical discussions about strictness and lifted types. Haskell protocol-buffers version 0.3.1. Chris Kuklewicz [6]announced the release of [7]protocol-buffers 0.3.1, with some functionality also split off into [8]protocol-buffers-descriptor and [9]hprotoc. The 'hprotoc' compiler for proto files to Haskell source code now takes a "-u" command-line option. When given, this turns on code generation to support loading, storing, and saving unknown fields. Discussion Stacking monads. Andrew Coppin began a long [10]discussion on monads, monad transformers, Applicative, MonadPlus, and related topics. planning for ghc-6.10.1 and hackage. Duncan Coutts began a [11]discussion on how to make the transition to GHC 6.10 as painless as possible, especially as it relates to the new base-4 package and Cabal. Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith. Bart Massey [12]proposed refactoring nub into a 'nubWith' function which can be specialized to efficient versions for Int and Ord. Blog noise [13]Haskell news from the [14]blogosphere. * Luke Palmer: [15]Laziness and the monad laws. Luke explains why making a Functor or Monad instance too lazy can be just as bad as making it too strict. * Paul R Brown: [16]The Haskell Platform and Lessons Learned Elsewhere. * Eric Kow (kowey): [17]darcs weekly news #6. * Mads Lindstroem: [18]Overlapping Instances in Haskell. * >>> Bill Six: [19]Dabbling with Haskell. Bill explores palindromic pangrams using Haskell. Quotes of the Week * ozy`: [on RWH] most authors are like "FUNCTIONAL PROGRAMMING IS FUNCTIONAL!!!" whereas these guys are more like "yeah but practical programming is practical. map wash_dish dishes" * BMeph: * wants an "Everything I know about computing I learned from sigfpe" T-shirt * OlegFacts: Oleg can evaluate bottom. With his fists. * quicksilver: my computer starts to play 'Dies Irae' when shapr gets ops, automatically. About the Haskell Weekly News New editions are posted to [20]the Haskell mailing list as well as to [21]the Haskell Sequence and [22]Planet Haskell. [23]RSS is also available, and headlines appear on [24]haskell.org. To help create new editions of this newsletter, please see the information on [25]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [26]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://fantasticcontraption.com/ 3. http://article.gmane.org/gmane.comp.lang.haskell.cafe/45786 4. http://article.gmane.org/gmane.comp.lang.haskell.cafe/45586 5. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OneTuple 6. http://article.gmane.org/gmane.comp.lang.haskell.libraries/10134 7. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers 8. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers-descriptor 9. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hprotoc 10. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/45634 11. http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/15339 12. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/10133 13. http://planet.haskell.org/ 14. http://haskell.org/haskellwiki/Blog_articles 15. http://luqui.org/blog/archives/2008/10/03/laziness-and-the-monad-laws/ 16. http://mult.ifario.us/p/the-haskell-platform-and-lessons-learned-elsewhere 17. http://koweycode.blogspot.com/2008/10/darcs-weekly-news-6.html 18. http://lindstroem.wordpress.com/2008/09/27/inheritance-in-composites-and-overlapping-instances/ 19. http://billsix.blogspot.com/2008/10/dabbling-with-haskell.html 20. http://www.haskell.org/mailman/listinfo/haskell 21. http://sequence.complete.org/ 22. http://planet.haskell.org/ 23. http://sequence.complete.org/node/feed 24. http://haskell.org/ 25. http://haskell.org/haskellwiki/HWN 26. http://code.haskell.org/~byorgey/code/hwn/ From ivan.miljenovic at gmail.com Sun Oct 5 12:53:43 2008 From: ivan.miljenovic at gmail.com (Ivan Miljenovic) Date: Sun Oct 5 12:50:13 2008 Subject: [Haskell] ANNOUNCE: SourceGraph-0.1 and Graphalyze-0.3 Message-ID: I've now uploaded my SourceGraph program to Hackage [1]. It's rather simple at the moment, but if you pass in the .cabal file as a parameter (e.g. run it as "SourceGraph Foo.cabal"), it will create in the same directory as the .cabal file a Directory called "SourceGraph" that contains an html report of some basic graph-theoretic analysis of your code. The output format isn't ideal, but it should serve it's purpose for now (I'll fix it up and actually make it usable once my Thesis has been handed in). What I'd appreciate if people could try it out and tell me if there's any code, etc. that it can't parse. At the moment, it ignores all Data-based functions (e.g. class and instance declarations as well as record functions) and only looks at "stand-alone" functions (i.e. normal functions). SourceGraph requires version 0.3 of my Graphalyze library (version 0.2 added the reports in, but had some bugs that 0.3 fixes). [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SourceGraph -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com From gwern0 at gmail.com Sun Oct 5 16:29:05 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Oct 5 16:38:14 2008 Subject: [Haskell] ANNOUNCE: SourceGraph-0.1 and Graphalyze-0.3 In-Reply-To: References: Message-ID: <20081005202905.GA23306@craft> 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/attachments/20081005/2484efb1/attachment-0001.bin From chak at cse.unsw.edu.au Tue Oct 7 06:43:41 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Oct 7 06:40:07 2008 Subject: [Haskell] DAMP 2009 CFP reminder & revised full paper deadline Message-ID: <036889EA-6AEA-4294-96F2-3B0619D80871@cse.unsw.edu.au> [Note the revised full paper submission date.] CALL FOR PAPERS DAMP 2009: Workshop on Declarative Aspects of Multicore Programming Savannah, GA, USA (co-located with POPL 2009) January 20, 2009 ABSTRACT SUBMISSION DEADLINE: OCTOBER 10 http://www.cse.unsw.edu.au/~pls/damp09/ Important Dates: Deadline for abstract submission: October 10, 2008 Deadline for full paper submission: October 14, 2008 Notification of acceptance: November 10, 2008 Final papers due: November 17, 2008 DAMP 2009: January 20, 2009 DAMP 2009 is the fourth in a series of one-day workshops seeking to explore ideas in programming language design that will greatly simplify programming for multicore architectures, and more generally for tightly coupled parallel architectures. DAMP 2009 is co-located with the ACM SIGPLAN - SIGACT Symposium on Principles of Programming Languages (POPL 2009). Scope The emphasis will be on functional and (constraint-)logic programming, but any programming language ideas that aim to raise the level of abstraction are welcome. DAMP seeks to gather together researchers in declarative approaches to parallel programming and to foster cross fertilization across different approaches. Specific topics include, but are not limited to: * suitability of functional and (constraint-)logic programming languages to multicore applications; * run-time issues such as garbage collection or thread scheduling; * architectural features that may enhance the parallel performance of declarative languages; * type systems and analysis for accurately knowing or limiting dependencies, aliasing, effects, and nonpure features; * ways of specifying or hinting at parallelism; * ways of specifying or hinting at data placement which abstract away from any details of the machine; * compiler techniques, automatic parallelization, automatic granularity control; * experiences of and challenges arising from making declarative programming practical; * technology for debugging parallel programs; * design and implementation of domain-specific declarative languages for multi-core; Accepted papers will be published in the ACM Digital Library and in a physical proceedings. Papers must adhere to the SIGPLAN Republication Policy: http://www.sigplan.org/republicationpolicy.htm Concurrent submissions to other conferences, workshops, journals, or similar forums of publication are not allowed. However, DAMP is intended to be a venue for discussion and exploration of works-in-progress, and so publication of a paper at DAMP 2009 is not intended to preclude later publication as appropriate. Submission Details: Authors should submit an abstract of at most 300 words and a full paper of no more than 10 pages (including bibliography and appendices) in the ACM SIGPLAN conference format. Further details are on the workshop web page: http://www.cse.unsw.edu.au/~pls/damp09/submission.html Program Chair: Manuel Chakravarty University of New South Wales Program Committee: Guy Blelloch Carnegie Mellon University Manuel Carro Universidad Polit?cnica de Madrid Koen Claessen Chalmers University of Technology Matthew Fluet Toyota Technological Institute at Chicago Vivek Sarkar Rice University Sven-Bodo Scholz University of Hertfordshire Satnam Singh Microsoft Research, Cambridge Martin Sulzmann IT University of Copenhagen Don Syme Microsoft Research, Cambridge Phil Trinder Heriot-Watt University General Chair: Leaf Petersen Intel Corporation Past DAMPs: http://www.cliplab.org/Conferences/DAMP08 http://glew.org/damp2006 http://www.cs.cmu.edu/~damp From bernardy at chalmers.se Wed Oct 8 07:10:22 2008 From: bernardy at chalmers.se (Jean-Philippe Bernardy) Date: Wed Oct 8 07:06:43 2008 Subject: [Haskell] Announce: Yi 0.5.0.1 Message-ID: <953e0d250810080410k663ff265n9e2d81c943370ba9@mail.gmail.com> I'm pleased to announce the 0.5 release of the Yi editor. ## Yi Yi is a text editor written and extensible in Haskell. The long-term goal of the Yi project is to provide the editor of choice for Haskell programmers. Yi is not a finished product. This is a beta-quality release. However, Yi has become a lot more usable than previously, so if you feel like testing it, now might be a good time to take a look. ## Installation Using cabal install: cabal install yi-0.5.0.1 If you want unix console support, pass the -fvty option to cabal install. ## Features * A purely functional editor core * Key-bindings written as parsers of the input * Emacs, Vim and partial Cua emulations provided by default * Unix Console front-end (Gtk2Hs frontend is not supported in this release) * Static configuration (XMonad style) for fast load * Haskell support: * Lexical highlighting * Layout-aware parenthesis-matching * Auto-indentation * cabal-build within the editor ## Links * [download](http://hackage.haskell.org/cgi-bin/hackage-scripts/package/yi) * [FAQ](http://haskell.org/haskellwiki/Yi/FAQ) * [homepage](http://haskell.org/haskellwiki/Yi) * [blog and release notes](http://yi-editor.blogspot.com/) * [check and report issues](http://code.google.com/p/yi-editor/issues/list) * [darcs repository](http://code.haskell.org/yi) * [get involved](mailto:yi-devel@googlegroups.com) ## Credits This release is brought to you by: * Allan Clark * Corey O'Connor * Gustav Munkby * Gwern Branwen * Jean-Philippe Bernardy * Jeff Wheeler * Nicolas Pouillard * Thomas Schilling * Tristan Allwood and all the contributors to the previous versions. From alfonso.acosta at gmail.com Wed Oct 8 07:35:34 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Wed Oct 8 07:31:53 2008 Subject: [Haskell] Announce: Yi 0.5.0.1 In-Reply-To: <953e0d250810080410k663ff265n9e2d81c943370ba9@mail.gmail.com> References: <953e0d250810080410k663ff265n9e2d81c943370ba9@mail.gmail.com> Message-ID: <6a7c66fc0810080435u69f9157aucbb913d05f8875a4@mail.gmail.com> On Wed, Oct 8, 2008 at 1:10 PM, Jean-Philippe Bernardy wrote: > I'm pleased to announce the 0.5 release of the Yi editor. I've just tested it and seems to work nicely, thanks. > * Unix Console front-end (Gtk2Hs frontend is not supported in this release) What ever happened to the experimental cocoa frontend? I'm sure a lot of Haskell hackers use OSX :) > * Haskell support: > * Lexical highlighting > * Layout-aware parenthesis-matching > * Auto-indentation > * cabal-build within the editor Some features I would love to see in Yi (I will add them to the tracker). * Automatic generation of module header templates (i.e. author, module name, license ... ) based on the project's Cabal file * Integration with darcs. * Automatic identifier completion and on-the-fly checking of code (e.g. type-checking) and haddock markup. From agocorona at gmail.com Wed Oct 8 07:57:16 2008 From: agocorona at gmail.com (Alberto G. Corona ) Date: Wed Oct 8 07:53:36 2008 Subject: [Haskell] Announce: Yi 0.5.0.1 In-Reply-To: <953e0d250810080410k663ff265n9e2d81c943370ba9@mail.gmail.com> References: <953e0d250810080410k663ff265n9e2d81c943370ba9@mail.gmail.com> Message-ID: and.. integrated compiler error location in source code; Very important for rapid application development and overall: Integrated GHCI debugger: VERY important for Haskell Newbies. for understanding the haskell execution strategy. for interactive teaching. 2008/10/8 Jean-Philippe Bernardy > I'm pleased to announce the 0.5 release of the Yi editor. > > ## Yi > Yi is a text editor written and extensible in Haskell. The > long-term goal of the Yi project is to provide the editor of > choice for Haskell programmers. > > Yi is not a finished product. This is a beta-quality release. However, Yi > has > become a lot more usable than previously, so if you feel like testing it, > now > might be a good time to take a look. > > ## Installation > Using cabal install: > > cabal install yi-0.5.0.1 > > If you want unix console support, pass the -fvty option to cabal install. > > ## Features > * A purely functional editor core > * Key-bindings written as parsers of the input > * Emacs, Vim and partial Cua emulations provided by default > * Unix Console front-end (Gtk2Hs frontend is not supported in this release) > > * Static configuration (XMonad style) for fast load > * Haskell support: > * Lexical highlighting > * Layout-aware parenthesis-matching > * Auto-indentation > * cabal-build within the editor > > ## Links > * [download](http://hackage.haskell.org/cgi-bin/hackage-scripts/package/yi > ) > * [FAQ](http://haskell.org/haskellwiki/Yi/FAQ) > * [homepage](http://haskell.org/haskellwiki/Yi) > * [blog and release notes](http://yi-editor.blogspot.com/) > * [check and report issues](http://code.google.com/p/yi-editor/issues/list > ) > * [darcs repository](http://code.haskell.org/yi) > * [get involved](mailto:yi-devel@googlegroups.com) > > ## Credits > > This release is brought to you by: > > * Allan Clark > * Corey O'Connor > * Gustav Munkby > * Gwern Branwen > * Jean-Philippe Bernardy > * Jeff Wheeler > * Nicolas Pouillard > * Thomas Schilling > * Tristan Allwood > > and all the contributors to the previous versions. > _______________________________________________ > 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/attachments/20081008/aebc4a63/attachment.htm From voigt at tcs.inf.tu-dresden.de Wed Oct 8 08:22:12 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Wed Oct 8 08:18:41 2008 Subject: [Haskell] Call for Contributions - Haskell Communities and Activities Report, November 2008 edition Message-ID: <48ECA5F4.3050801@tcs.inf.tu-dresden.de> Dear Haskellers, so much has happened in the Haskell world in the past months. Therefore, I would very much like to collect contributions for the 15th edition of the ================================================================ Haskell Communities & Activities Report http://www.haskell.org/communities/ Submission deadline: 31 October 2008 (please send your contributions to hcar@haskell.org, in plain text or LaTeX format) ================================================================ This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough -- please reconsider and submit an entry anyway! * If you are interested in any project related to Haskell that has not previously been mentioned in the HC&A Report, please tell me, so that I can contact the project leaders and ask them to submit an entry. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities & Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming six months. If you have only recently been exposed to Haskell, it might be a good idea to browse the May 2008 edition -- you will find interesting topics described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! Looking forward to your contributions, Janis (current editor) FAQ: Q: What format should I write in? A: The best format is a LaTeX source file, adhering to the template that is available at: http://haskell.org/communities/11-2008/template.tex There is also a LaTeX style file at http://haskell.org/communities/11-2008/hcar.sty that you can use to preview your entry. If you do not know LaTeX, then use plain text. If you modify an old entry that you have written for an earlier edition of the report, you should have received your old entry as a template already (provided I have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. Do not worry about writing correct LaTeX, I will be able to handle your file. Please do not use HTML or even DOC. Q: Can I include images? A: Yes, you are even encouraged to do so. Please use .jpg format, then. Q: How much should I write? A: Authors are asked to limit entries to about one column of text. This corresponds to approximately one page, or 40 lines of text, with the above style and template. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. Pointers to online content can be given for more comprehensive or ``historic'' overviews of a project. Images do not count towards the length limit, so you may want to use this opportunity to pep entries up. There is no minimum length of an entry! The report aims at being as complete as possible, so please consider writing an entry, even if it is only a few lines long. Q: Which topics are relevant? A: All topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports over distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we do not even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also ask the editor. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. You can use it to write ``wishlist'' items for libraries and language features you would like to see implemented. Q: If I do not update my entry, but want to keep it in the report, what should I do? A: Tell the editor that there are no changes. The old entry will be reused in this case, but it might be dropped if it is older than a year, to give more room and more attention to projects that change a lot. Do not resend complete entries if you have not changed them. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From p.k.f.holzenspies at utwente.nl Wed Oct 8 10:37:49 2008 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?utf-8?q?H=C3=B6lzenspies?=) Date: Wed Oct 8 10:34:13 2008 Subject: [Haskell] Catching error / making library functions monadic (in failure) Message-ID: <200810081637.49352.p.k.f.holzenspies@utwente.nl> Dear Hask'lers, I'm working on a graph generator that involves a lot of random selection out of a list of vertices. Basically, there are functions that look a little like this: select vs = randomRM (0,length vs - 1) >>= return . (vs !!) where randomRM is a lot like Random.randomRIO, except that it is not in the IO monad, but rather in any monad, i.e. class Monad m => RandomM m where randomM :: m a randomRM :: (a,a) -> m a instance RandomM IO where randomM = randomIO randomRM = randomRIO The problem is, obviously, that when the list of vertices (vs) is empty, "select vs" will result in an error. The Prelude defines (!!) as: xs !! n | n < 0 = error "Prelude.!!: negative index" [] !! _ = error "Prelude.!!: index too large" (x:_) !! 0 = x (_:xs) !! n = xs !! (n-1) The function 'error' is implemented (at least in GHC) using Control.Exception.throw. Unfortunately, 'catch' does not seem to work. From ghci: Prelude> catch (return $ [] !! 0) (const $ putStrLn "foo" >> return 42) *** Exception: Prelude.(!!): index too large Is there any way to catch errors in functions in libraries (like the Prelude)? This is made even more necessary by the fact that the default implementation for 'fail' in a monad is 'error'. I would already be happy if I could make all applications of error change into applications of fail, as defined in my monad. Preferably, though, I would not even need a failure mechanism in my own monad, but rather have an ErrorMonad (or something similar) and just have class Monad m => ErrorMonad error m | m -> error where onError :: m a -> (error -> a) -> a For now, I simply reimplement the functions I need that give errors. Regards, Philip From neil.mitchell.2 at credit-suisse.com Wed Oct 8 10:42:16 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Wed Oct 8 10:39:34 2008 Subject: [Haskell] Catching error / making library functions monadic (in failure) In-Reply-To: <200810081637.49352.p.k.f.holzenspies@utwente.nl> References: <200810081637.49352.p.k.f.holzenspies@utwente.nl> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD3ADE@ELON17P32001A.csfb.cs-group.com> Hi Philip, You might want to take a look at the Safe library, which does pretty close to what you request. http://www-users.cs.york.ac.uk/~ndm/safe/ (or cabal install safe) I would happily accept a patch adding *Fail variants that failed in some appropriate Monad if that is what you want. Thanks Neil > -----Original Message----- > From: haskell-bounces@haskell.org > [mailto:haskell-bounces@haskell.org] On Behalf Of Philip K.F. > H?lzenspies > Sent: 08 October 2008 3:38 pm > To: haskell@haskell.org > Subject: [Haskell] Catching error / making library functions > monadic (in failure) > > Dear Hask'lers, > > I'm working on a graph generator that involves a lot of > random selection out of a list of vertices. Basically, there > are functions that look a little like > this: > > select vs = randomRM (0,length vs - 1) >>= return . (vs !!) > > where randomRM is a lot like Random.randomRIO, except that it > is not in the IO monad, but rather in any monad, i.e. > > class Monad m => RandomM m where > randomM :: m a > randomRM :: (a,a) -> m a > > instance RandomM IO where > randomM = randomIO > randomRM = randomRIO > > The problem is, obviously, that when the list of vertices > (vs) is empty, "select vs" will result in an error. The > Prelude defines (!!) as: > > xs !! n | n < 0 = error "Prelude.!!: negative index" > [] !! _ = error "Prelude.!!: index too large" > (x:_) !! 0 = x > (_:xs) !! n = xs !! (n-1) > > The function 'error' is implemented (at least in GHC) using > Control.Exception.throw. Unfortunately, 'catch' does not seem > to work. From > ghci: > > Prelude> catch (return $ [] !! 0) (const $ putStrLn "foo" >> > return 42) > *** Exception: Prelude.(!!): index too large > > Is there any way to catch errors in functions in libraries > (like the Prelude)? > This is made even more necessary by the fact that the default > implementation for 'fail' in a monad is 'error'. I would > already be happy if I could make all applications of error > change into applications of fail, as defined in my monad. > Preferably, though, I would not even need a failure mechanism > in my own monad, but rather have an ErrorMonad (or something > similar) and just have > > class Monad m => ErrorMonad error m | m -> error where > onError :: m a -> (error -> a) -> a > > For now, I simply reimplement the functions I need that give errors. > > Regards, > Philip > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From p.k.f.holzenspies at utwente.nl Wed Oct 8 10:58:27 2008 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?iso-8859-1?q?H=F6lzenspies?=) Date: Wed Oct 8 10:54:50 2008 Subject: [Haskell] Catching error / making library functions monadic (in failure) In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD3ADE@ELON17P32001A.csfb.cs-group.com> References: <200810081637.49352.p.k.f.holzenspies@utwente.nl> <33A3F585590A6F4E81E3D45AA4A111C902CD3ADE@ELON17P32001A.csfb.cs-group.com> Message-ID: <200810081658.27953.p.k.f.holzenspies@utwente.nl> On Wednesday 08 October 2008 16:42:16 Mitchell, Neil wrote: > You might want to take a look at the Safe library, which does pretty close > to what you request. > > http://www-users.cs.york.ac.uk/~ndm/safe/ > > (or cabal install safe) > > I would happily accept a patch adding *Fail variants that failed in some > appropriate Monad if that is what you want. Dear Mitchell, This is what I want, but only for those functions. I use quite a few functions that produce errors (also from gtk2hs). These functions have been programmed using "error." Would these functions have been programmed with "abort," all would be honkey-dory. That is, unfortunately, not the case, so I'm still looking for a way to catch the existing errors thrown. In the smallest scenario: some_catch_function (error "foo") (error "bar") should result in an error "bar" Regards, Philip From aslatter at gmail.com Wed Oct 8 11:35:06 2008 From: aslatter at gmail.com (Antoine Latter) Date: Wed Oct 8 11:31:26 2008 Subject: [Haskell] Catching error / making library functions monadic (in failure) In-Reply-To: <200810081658.27953.p.k.f.holzenspies@utwente.nl> References: <200810081637.49352.p.k.f.holzenspies@utwente.nl> <33A3F585590A6F4E81E3D45AA4A111C902CD3ADE@ELON17P32001A.csfb.cs-group.com> <200810081658.27953.p.k.f.holzenspies@utwente.nl> Message-ID: <694519c50810080835t66631ea6y9cf3ac338c3ee401@mail.gmail.com> On Wed, Oct 8, 2008 at 9:58 AM, Philip K.F. H?lzenspies wrote: > > some_catch_function (error "foo") (error "bar") > > should result in an error "bar" > It's a good thing we've already got a function for that! > Prelude.catch (error "foo") (error "bar") *** Exception: foo > Control.Exception.catch (error "foo") (error "bar") *** Exception: bar -Antoine From duncan.coutts at worc.ox.ac.uk Wed Oct 8 11:28:19 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 8 11:49:38 2008 Subject: [Haskell] Catching error / making library functions monadic (in failure) In-Reply-To: <200810081658.27953.p.k.f.holzenspies@utwente.nl> References: <200810081637.49352.p.k.f.holzenspies@utwente.nl> <33A3F585590A6F4E81E3D45AA4A111C902CD3ADE@ELON17P32001A.csfb.cs-group.com> <200810081658.27953.p.k.f.holzenspies@utwente.nl> Message-ID: <1223479699.14163.661.camel@dell.linuxdev.us.dell.com> On Wed, 2008-10-08 at 16:58 +0200, Philip K.F. H?lzenspies wrote: > Is there any way to catch errors in functions in libraries (like the > Prelude)? Yes. Use Control.Exception.catch The catch in the Prelude is only for catching IO errors. It cannot catch errors thrown from pure code. Note that you can only catch exceptions in IO. > I use quite a few functions that produce errors (also from gtk2hs). > These functions have been programmed using "error." Would these > functions have been programmed with "abort," all would be honkey-dory. Which gtk2hs functions that you're using use error? It would be interesting to know which ones are a problem. I thought gtk2hs mostly throws exceptions in IO (which can be caught in IO) except for some rare cases which would always be programming errors. If you can report them we can fix them. Duncan From martijn at van.steenbergen.nl Wed Oct 8 13:45:36 2008 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Wed Oct 8 13:42:10 2008 Subject: [Haskell] Catching error / making library functions monadic (in failure) In-Reply-To: <200810081658.27953.p.k.f.holzenspies@utwente.nl> References: <200810081637.49352.p.k.f.holzenspies@utwente.nl> <33A3F585590A6F4E81E3D45AA4A111C902CD3ADE@ELON17P32001A.csfb.cs-group.com> <200810081658.27953.p.k.f.holzenspies@utwente.nl> Message-ID: <48ECF1C0.4010301@van.steenbergen.nl> Hi Philip, Philip K.F. H?lzenspies wrote: > some_catch_function (error "foo") (error "bar") > > should result in an error "bar" Take a look at the isBottom function which is defined in module Test.QuickCheck.Batch; it might be of value to you: isBottom :: a -> Bool isBottom a = unsafePerformIO (do a' <- try (Exception.evaluate a) case a' of Left _ -> return True Right _ -> return False) Regards, Martijn. From p.k.f.holzenspies at utwente.nl Thu Oct 9 03:51:57 2008 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?iso-8859-1?q?H=F6lzenspies?=) Date: Thu Oct 9 03:48:16 2008 Subject: [Haskell] SOLVED Catching error / making library functions monadic (in failure) In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD3ADE@ELON17P32001A.csfb.cs-group.com> References: <200810081637.49352.p.k.f.holzenspies@utwente.nl> <33A3F585590A6F4E81E3D45AA4A111C902CD3ADE@ELON17P32001A.csfb.cs-group.com> Message-ID: <200810090951.57774.p.k.f.holzenspies@utwente.nl> Dear all, Thank you very much for your reactions. Neil told me I should have posted this in haskell-cafe, so sorry for the inconvenience. Since my problem has since been solved, I figured I would send this "thanks all, it's solve" e-mail to the list, to close the issue. The magic answer turned out to be Control.Exception.evaluate as opposed to return. This was the problem: catch (return $ [] !! 0) (error "foo") (which I had oversimplified by omitting the return) gave *** Exception: Prelude.(!!): index too large while catch (evaluate $ [] !! 0) (error "foo") gave *** Exception: bar even when unsafePerformIO was applied to it. Thank you all, but especially the people that suggested this: Martijn & Koen Regards, Philip From kowey at darcs.net Thu Oct 9 11:20:23 2008 From: kowey at darcs.net (Eric Kow) Date: Thu Oct 9 11:16:45 2008 Subject: [Haskell] ANNOUNCE: darcs 2.1.0 Message-ID: <20081009152023.GD20340@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: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20081009/cb090b2a/attachment-0001.bin From kowey at darcs.net Thu Oct 9 12:02:29 2008 From: kowey at darcs.net (Eric Kow) Date: Thu Oct 9 11:58:45 2008 Subject: [Haskell] Re: ANNOUNCE: darcs 2.1.0 In-Reply-To: <20081009152023.GD20340@brighton.ac.uk> References: <20081009152023.GD20340@brighton.ac.uk> Message-ID: <4a0b969d0810090902g3824b8e9q88935d03bc737407@mail.gmail.com> > This version provides over 40 bug fixes and 20 new features since > darcs 2.0.2. The most notable changes are: Correction! That's 20 bug fixes and 7 new features. Sorry about that (I had mis-grepped the ChangeLog) -- Eric Kow PGP Key ID: 08AC04F9 From marcot at riseup.net Fri Oct 10 00:39:15 2008 From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva) Date: Fri Oct 10 00:36:27 2008 Subject: [Haskell] Catching error / making library functions monadic (in failure) In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD3ADE@ELON17P32001A.csfb.cs-group.com> References: <200810081637.49352.p.k.f.holzenspies@utwente.nl> <33A3F585590A6F4E81E3D45AA4A111C902CD3ADE@ELON17P32001A.csfb.cs-group.com> Message-ID: <1223613555.15283.49.camel@quindinho.domain.invalid> Hello, Op woensdag 08-10-2008 om 15:42 uur [tijdzone +0100], schreef Mitchell, Neil: > http://www-users.cs.york.ac.uk/~ndm/safe/ I think takeDef should be tailDef, in this page. Greetings. -- marcot P?gina: http://marcotmarcot.iaaeee.org/ Blog: http://marcotmarcot.blogspot.com/ Correio: marcot@riseup.net XMPP: marcot@jabber.org IRC: marcot@irc.freenode.net Telefone: 25151920 Celular: 98116720 Endere?o: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil From ryani.spam at gmail.com Fri Oct 10 04:57:07 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Fri Oct 10 04:53:21 2008 Subject: [Haskell] ANNOUNCE: ListZipper-1.1.0.0 Message-ID: <2f9b2d30810100157h57e21eb1l39054d0236fbc907@mail.gmail.com> I was surprised to find there was no simple zipper for [] on hackage, so I made one: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ListZipper-1.1.0.0 (1.0.0.0 had a dumb bug where I switched right and left!) Example in ghci: Prelude Data.List.Zipper> let z = fromList [1,2,3] Prelude Data.List.Zipper> toList (replace 5 $ right z) [1,5,3] -- ryan From alfonso.acosta at gmail.com Fri Oct 10 09:33:59 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Fri Oct 10 09:30:20 2008 Subject: [Haskell] Re: [Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell In-Reply-To: <48EF46B1.9070500@gmail.com> References: <48EF46B1.9070500@gmail.com> Message-ID: <6a7c66fc0810100633y5f0c94drcc41a33b72f2a38a@mail.gmail.com> Great! Are there any chances of getting support for non-Win32 platforms with Mono? On Fri, Oct 10, 2008 at 2:12 PM, Andrew Appleyard wrote: > I'd like to announce the first release of Salsa, an experimental Haskell > library that allows Haskell programs to access .NET libraries. > > Here's a taste: > > > type Hello.hs > import Foreign.Salsa > import Bindings > > main = withCLR $ do > _Console # _writeLine ("Hello .NET World!") > > > type Hello.imports > System.Console: WriteLine > > > msbuild > > .\hello > Hello .NET World! > > Salsa operates by loading the .NET runtime into your Haskell process and > using the FFI (and run-time code generation) to marshall calls between the > .NET and Haskell runtimes. It includes a code generator and a type-level > library (which uses type families) to provide type-safe access to .NET > libraries in Haskell with C#-style method overload resolution and implicit > conversions. > > The adventurous can find version 0.1.0.1 of Salsa on Hackage [1], the darcs > repository on code.haskell.org [2], and some (limited) documentation on the > Haskell wiki [3]. > > The library is experimental and by no means complete (refer to the wiki page > [3] for some of its limitations). Be prepared to end up with > incomprehensible error messages and/or a broken compiler! :-) > > At the moment you'll need Windows, GHC 6.8, and version 3.5 of the .NET > Framework to use it. > > Have fun! > > [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Salsa > [2] http://code.haskell.org/Salsa > [3] http://haskell.org/haskellwiki/Salsa > > -- > Andrew > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dons at galois.com Fri Oct 10 13:44:11 2008 From: dons at galois.com (Don Stewart) Date: Fri Oct 10 13:40:19 2008 Subject: [Haskell] Re: [Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell In-Reply-To: <48EF46B1.9070500@gmail.com> References: <48EF46B1.9070500@gmail.com> Message-ID: <20081010174411.GA6102@scytale.galois.com> This could be a game changer. Great work Andrew!! -- Don andrew.appleyard: > I'd like to announce the first release of Salsa, an experimental Haskell > library that allows Haskell programs to access .NET libraries. > > Here's a taste: > > > type Hello.hs > import Foreign.Salsa > import Bindings > > main = withCLR $ do > _Console # _writeLine ("Hello .NET World!") > > > type Hello.imports > System.Console: WriteLine > > > msbuild > > .\hello > Hello .NET World! > > Salsa operates by loading the .NET runtime into your Haskell process and > using the FFI (and run-time code generation) to marshall calls between > the .NET and Haskell runtimes. It includes a code generator and a > type-level library (which uses type families) to provide type-safe > access to .NET libraries in Haskell with C#-style method overload > resolution and implicit conversions. > > The adventurous can find version 0.1.0.1 of Salsa on Hackage [1], the > darcs repository on code.haskell.org [2], and some (limited) > documentation on the Haskell wiki [3]. > > The library is experimental and by no means complete (refer to the wiki > page [3] for some of its limitations). Be prepared to end up with > incomprehensible error messages and/or a broken compiler! :-) > > At the moment you'll need Windows, GHC 6.8, and version 3.5 of the .NET > Framework to use it. > > Have fun! > > [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Salsa > [2] http://code.haskell.org/Salsa > [3] http://haskell.org/haskellwiki/Salsa > > -- > Andrew > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From niklas.broberg at gmail.com Fri Oct 10 15:02:20 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Fri Oct 10 14:58:31 2008 Subject: [Haskell] Re: [Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell In-Reply-To: <20081010174411.GA6102@scytale.galois.com> References: <48EF46B1.9070500@gmail.com> <20081010174411.GA6102@scytale.galois.com> Message-ID: > This could be a game changer. > > Great work Andrew!! Totally agreed, on both accounts. Really interesting to see. > -- Don What, no Arch Linux port? :-) Cheers, /Niklas From ivan.miljenovic at gmail.com Sun Oct 12 09:54:44 2008 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Sun Oct 12 09:51:00 2008 Subject: [Haskell] ANNOUNCE: Graphalyze-0.4 and SourceGraph-0.2 Message-ID: <20081012235444.18600479@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like to announce version 0.4 of my Graphalyze library [1] and 0.2 of my SourceGraph programme [2]. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Graphalyze [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SourceGraph This should fix the bugs reported by Gwern Branwen, Magnus Therning (thanks to Niklas Broberg for stating the correct version for Haskell-Src-Exts) and Christopher Hinson. No really new features are included in this release. I was planning on fixing this and releasing it sooner but - to utilise what seems to be a current meme [3] - "I accidentally my Gentoo" on Tuesday night and only fixed it yesterday. [3] http://encyclopediadramatica.com/I_accidentally_X Since I'm more awake now than I was when I made the initial release, here's a run-down of what SourceGraph is: SourceGraph is a programme designed to help you analyse the static complexity of your Haskell code when represented as a graph. At the moment, it does the following (M == for each module, I = for imports, C = the whole codebase): * Visualise it {M,I,C} * See a "collapsed" visualisation {M} * Proposed module/directory layout using two different algorithms {I,C} * See the "core" visualisation (recursively strip off roots/leaves) {M} * Calculate the Cyclomatic complexity [4] {M,I,C} * Root analysis (compare what's exported to what actually is a root) {M,I,C} * Determine how many components you have, to see if you should split {M,I,C} * Clique Analysis (find co-recursive functions) {M,C} * Cycle analysis (non-cliques) {M,I,C} * Chain detection (e.g. "straight-line" functions/imports) {M,I,C} [4] http://en.wikipedia.org/wiki/Cyclomatic_complexity Current limitations: * An automatic refactoring tool: SourceGraph gives *you* information on how you might want to possibly refactor your code. It's not smart: it can't tell that you've clumped functions foo and bar in the same module because they do similar things or because it's a utility module, even though they're not related. For automatic refactoring, see something like HaRe [5]. * SourceGraph ignore's "data-based" functions, i.e. record-functions and class/instance declarations, as it's too confusing (IMHO) which actual function you mean (if you see "show" being called, is it for Int, Double, or something else?). * Despite using Haskell-Src-Exts, some extensions (e.g. TH) are ignored, mainly because I have no idea how they work and nothing to test it on. GHC extensions should be supported (read the parser won't choke on them) though. * Reporting output is currently rather limited: - The report will be generated in a subdirectory called "SourceGraph" of the codebase directory; this is currently hardwired in. - It will produce an all-in-one html file report, with no fancy CSS magic to make it look pretty. Ideally, it would produce a split-file, and allow you to choose output format. - Large graphs are shrunk down to being a maximum of 15"x10". Ideally, I'd like to extend this later so that large graphs will have a shrunk version in the graph, which link to a larger version (note though that these graphs get very large very fast). - The output of individual function names, etc. could be improved. [5] http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html SourceGraph can be installed with cabal-install. Once you've done so, you can analyse a cabalized library/application Foo as follows: $ SourceGraph /path/to/codebase/Foo.cabal Report generated at: /path/to/codebase/SourceGraph/Foo.html This has been written as part of my mathematics Honours Thesis, "Graph-Theoretic Analysis of the Relationships in Discrete Data". Since I've actually got to write the thesis up now, I won't be making any more releases for a while. After uni is over for the semester though, I hope to tidy it up and extend it. If you want to check the code out yourselves, there's also darcs repositories for Graphalyze [6] and SourceGraph [7]. [6] http://code.haskell.org/Graphalyze [7] http://code.haskell.org/SourceGraph/ Note that whilst Graphalyze is fully documented, etc., the internals of SourceGraph are a bit fugly (mainly due to time constraints). Enjoy! - -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjyAacACgkQfEfFJ9JhvyiHEACfVVuRk2FR3ZQiJ6H18FFK/de/ sukAn0tuCLwqxmzlQvWicQKQ3qEJKC1K =HRUK -----END PGP SIGNATURE----- From marco-oweber at gmx.de Sun Oct 12 11:38:30 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Oct 12 11:34:39 2008 Subject: [Haskell] Could not deduce .. why ? Message-ID: <20081012153830.GA18606@gmx.de> Surely I've overseen a small point. But I can't see it: Why doesn't ghc recognize taht elc_ (class decl), elc (instance decl) and elc_1 are the same type To help you find the connecting pieces faster I've marked them with ## ## Marc data PT a b = PT b -- phantom type containing state a and the result b class AddEl el_ el2_ elc_ where addEl :: el_ -> elc -> el2_ -- el, child -- ========== adding sub elements (tags) ============================= class AddElT est el_ estc ##elc_## est2 el2_ | estc est -> est2 , est est2 estc el2_ -> el_ , est est2 estc el2_ -> elc_ where addElT :: PT est el_ -> PT estc ##elc_## -> PT est2 el2_ -- first child ? attrs ok? instance ( AddEl el el2 ##elc## <-- this is not recognized because elc != elc_1 , Consume st (Elem celType) st' , DetermineElAddEl (NYV (Element elType AttrsOk st HFalse)) el (Valid celType) elc (NYV (Element elType AttrsOk st' HTrue)) el2 ) => AddElT (NYV (Element elType AttrsOk st HFalse)) el (Valid celType) ##elc## <-- elc_ from class declaration (NYV (Element elType AttrsOk st' HTrue)) el2 where addElT (PT t) (PT ##c##) = PT $ addEl t c -- <<<<<<<<< line 435, c should have type elc, not elc_1 src/Text/XML/Validated/Types.hs|435 col 32 error| || Could not deduce (AddEl el el2 elc_1) || from the context (AddElT || (NYV (Element elType AttrsOk st HFalse)) || el || (Valid celType) || elc || (NYV (Element elType AttrsOk st' HTrue)) || el2, || AddEl el el2 elc, || Consume st (Elem celType) st', || DetermineElAddEl || (NYV (Element elType AttrsOk st HFalse)) || el || (Valid celType) || elc || (NYV (Element elType AttrsOk st' HTrue)) || el2) || arising from a use of `addEl' || at src/Text/XML/Validated/Types.hs:435:32-40 || Possible fix: || add (AddEl el el2 elc_1) to the context of the instance declaration || In the second argument of `($)', namely `addEl t c' || In the expression: PT $ addEl t c || In the definition of `addElT': || addElT (PT t) (PT c) = PT $ addEl t c From gwern0 at gmail.com Sun Oct 12 13:24:40 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Oct 12 13:21:49 2008 Subject: [Haskell] ANNOUNCE: Graphalyze-0.4 and SourceGraph-0.2 In-Reply-To: <20081012235444.18600479@gmail.com> References: <20081012235444.18600479@gmail.com> Message-ID: <20081012172440.GA4207@craft> On 2008.10.12 23:54:44 +1000, Ivan Lazar Miljenovic scribbled 6.4K characters: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'd like to announce version 0.4 of my Graphalyze library [1] and 0.2 of my > SourceGraph programme [2]. > > [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Graphalyze > [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SourceGraph > > This should fix the bugs reported by Gwern Branwen, Magnus Therning (thanks to > Niklas Broberg for stating the correct version for Haskell-Src-Exts) and > Christopher Hinson. No really new features are included in this release. I > was planning on fixing this and releasing it sooner but - to utilise what seems > to be a current meme [3] - "I accidentally my Gentoo" on Tuesday night and only > fixed it yesterday. > > [3] http://encyclopediadramatica.com/I_accidentally_X > > Since I'm more awake now than I was when I made the initial release, here's a > run-down of what SourceGraph is: > > SourceGraph is a programme designed to help you analyse the static complexity > of your Haskell code when represented as a graph. At the moment, it does the > following (M == for each module, I = for imports, C = the whole codebase): > > * Visualise it {M,I,C} > * See a "collapsed" visualisation {M} > * Proposed module/directory layout using two different algorithms {I,C} > * See the "core" visualisation (recursively strip off roots/leaves) {M} > * Calculate the Cyclomatic complexity [4] {M,I,C} > * Root analysis (compare what's exported to what actually is a root) {M,I,C} > * Determine how many components you have, to see if you should split {M,I,C} > * Clique Analysis (find co-recursive functions) {M,C} > * Cycle analysis (non-cliques) {M,I,C} > * Chain detection (e.g. "straight-line" functions/imports) {M,I,C} > > [4] http://en.wikipedia.org/wiki/Cyclomatic_complexity > > Current limitations: > > * An automatic refactoring tool: SourceGraph gives *you* information on how you > might want to possibly refactor your code. It's not smart: it can't tell > that you've clumped functions foo and bar in the same module because they do > similar things or because it's a utility module, even though they're not > related. For automatic refactoring, see something like HaRe [5]. > * SourceGraph ignore's "data-based" functions, i.e. record-functions and > class/instance declarations, as it's too confusing (IMHO) which actual > function you mean (if you see "show" being called, is it for Int, Double, or > something else?). > * Despite using Haskell-Src-Exts, some extensions (e.g. TH) are ignored, mainly > because I have no idea how they work and nothing to test it on. GHC > extensions should be supported (read the parser won't choke on them) though. > * Reporting output is currently rather limited: > - The report will be generated in a subdirectory called "SourceGraph" of the > codebase directory; this is currently hardwired in. > - It will produce an all-in-one html file report, with no fancy CSS magic to > make it look pretty. Ideally, it would produce a split-file, and allow you > to choose output format. > - Large graphs are shrunk down to being a maximum of 15"x10". Ideally, I'd > like to extend this later so that large graphs will have a shrunk version > in the graph, which link to a larger version (note though that these graphs > get very large very fast). > - The output of individual function names, etc. could be improved. > > [5] http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html > > SourceGraph can be installed with cabal-install. Once you've done so, you can > analyse a cabalized library/application Foo as follows: > > $ SourceGraph /path/to/codebase/Foo.cabal > Report generated at: /path/to/codebase/SourceGraph/Foo.html > > This has been written as part of my mathematics Honours Thesis, > "Graph-Theoretic Analysis of the Relationships in Discrete Data". Since I've > actually got to write the thesis up now, I won't be making any more releases > for a while. After uni is over for the semester though, I hope to tidy it up > and extend it. > > If you want to check the code out yourselves, there's also darcs repositories > for Graphalyze [6] and SourceGraph [7]. > > [6] http://code.haskell.org/Graphalyze > [7] http://code.haskell.org/SourceGraph/ > > Note that whilst Graphalyze is fully documented, etc., the internals of > SourceGraph are a bit fugly (mainly due to time constraints). > > Enjoy! > > - -- > Ivan Lazar Miljenovic OK, I've installed and yes - it now produces output for XMC instead of looping. However, I happened to want to look at the output for one of my modules, XMonad.Util.XSelection - and it simply isn't there. Most of the XMC modules seem to be there, but that one isn't. It's in the cabal file, SourceGraph did not output any errors or warnings, but XSelection is not mentioned in the HTML output nor are any PNGs generated with regard to it. See: gwern@craft:24375~/bin/XMonadContrib/SourceGraph>grep XSelection ../xmonad-contrib.cabal [ 1:20PM] XMonad.Util.XSelection gwern@craft:24372~/bin/XMonadContrib>SourceGraph xmonad-contrib.cabal [ 1:16PM] Report generated at: SourceGraph/xmonad-contrib.html SourceGraph xmonad-contrib.cabal 59.05s user 4.14s system 98% cpu 1:03.83 total gwern@craft:24373~/bin/XMonadContrib>c SourceGraph [ 1:17PM] codeCluster.png XMonad.Layout.DragPane_collapsed.png codeCollapsed.png XMonad.Layout.DragPane.png codeCore.png XMonad.Layout.DwmStyle_collapsed.png codeCW.png XMonad.Layout.DwmStyle.png code.png XMonad.Layout.Gaps_collapsed.png codeRNG.png XMonad.Layout.Gaps.png importCluster.png XMonad.Layout.Grid_collapsed.png importCW.png XMonad.Layout.Grid.png importRNG.png XMonad.Layout.HintedGrid_collapsed.png imports.png XMonad.Layout.HintedGrid.png Main_collapsed.png XMonad.Layout.HintedTile_collapsed.png Main.png XMonad.Layout.HintedTile_core.png XMonad.Actions.Commands_collapsed.png XMonad.Layout.HintedTile.png XMonad.Actions.Commands.png XMonad.Layout.IM_collapsed.png XMonad.Actions.ConstrainedResize_collapsed.png XMonad.Layout.IM.png XMonad.Actions.ConstrainedResize.png XMonad.Layout.LayoutCombinators_collapsed.png XMonad.Actions.CopyWindow_collapsed.png XMonad.Layout.LayoutCombinators.png XMonad.Actions.CopyWindow.png XMonad.Layout.LayoutHints_collapsed.png XMonad.Actions.CycleRecentWS_collapsed.png XMonad.Layout.LayoutHints.png XMonad.Actions.CycleRecentWS.png XMonad.Layout.LayoutModifier_collapsed.png XMonad.Actions.CycleSelectedLayouts_collapsed.png XMonad.Layout.LayoutModifier.png XMonad.Actions.CycleSelectedLayouts.png XMonad.Layout.LayoutScreens_collapsed.png XMonad.Actions.CycleWS_collapsed.png XMonad.Layout.LayoutScreens.png XMonad.Actions.CycleWS_core.png XMonad.Layout.MagicFocus_collapsed.png XMonad.Actions.CycleWS.png XMonad.Layout.MagicFocus.png XMonad.Actions.DeManage_collapsed.png XMonad.Layout.Magnifier_collapsed.png XMonad.Actions.DeManage.png XMonad.Layout.Magnifier.png XMonad.Actions.DwmPromote_collapsed.png XMonad.Layout.Master_collapsed.png XMonad.Actions.DwmPromote.png XMonad.Layout.Master.png XMonad.Actions.DynamicWorkspaces_collapsed.png XMonad.Layout.Maximize_collapsed.png XMonad.Actions.DynamicWorkspaces.png XMonad.Layout.Maximize.png XMonad.Actions.FindEmptyWorkspace_collapsed.png XMonad.Layout.MosaicAlt_collapsed.png XMonad.Actions.FindEmptyWorkspace.png XMonad.Layout.MosaicAlt_core.png XMonad.Actions.FlexibleManipulate_collapsed.png XMonad.Layout.MosaicAlt.png XMonad.Actions.FlexibleManipulate.png XMonad.Layout.MultiToggle_collapsed.png XMonad.Actions.FlexibleResize_collapsed.png XMonad.Layout.MultiToggle.Instances_collapsed.png XMonad.Actions.FlexibleResize.png XMonad.Layout.MultiToggle.Instances.png XMonad.Actions.FloatKeys_collapsed.png XMonad.Layout.MultiToggle.png XMonad.Actions.FloatKeys.png XMonad.Layout.Named_collapsed.png XMonad.Actions.FocusNth_collapsed.png XMonad.Layout.Named.png XMonad.Actions.FocusNth.png XMonad.Layout.NoBorders_collapsed.png XMonad.Actions.MouseGestures_collapsed.png XMonad.Layout.NoBorders.png XMonad.Actions.MouseGestures.png XMonad.Layout.PerWorkspace_collapsed.png XMonad.Actions.MouseResize_collapsed.png XMonad.Layout.PerWorkspace.png XMonad.Actions.MouseResize.png XMonad.Layout.Reflect_collapsed.png XMonad.Actions.NoBorders_collapsed.png XMonad.Layout.Reflect.png XMonad.Actions.NoBorders.png XMonad.Layout.ResizeScreen_collapsed.png XMonad.Actions.PerWorkspaceKeys_collapsed.png XMonad.Layout.ResizeScreen.png XMonad.Actions.PerWorkspaceKeys.png XMonad.Layout.Roledex_collapsed.png XMonad.Actions.Plane_collapsed.png XMonad.Layout.Roledex.png XMonad.Actions.Plane.png XMonad.Layout.ShowWName_collapsed.png XMonad.Actions.Promote_collapsed.png XMonad.Layout.ShowWName.png XMonad.Actions.Promote.png XMonad.Layout.SimpleDecoration_collapsed.png XMonad.Actions.RotSlaves_collapsed.png XMonad.Layout.SimpleDecoration.png XMonad.Actions.RotSlaves.png XMonad.Layout.SimpleFloat_collapsed.png XMonad.Actions.Search_collapsed.png XMonad.Layout.SimpleFloat.png XMonad.Actions.Search.png XMonad.Layout.Simplest_collapsed.png XMonad.Actions.SimpleDate_collapsed.png XMonad.Layout.SimplestFloat_collapsed.png XMonad.Actions.SimpleDate.png XMonad.Layout.SimplestFloat.png XMonad.Actions.SinkAll_collapsed.png XMonad.Layout.Simplest.png XMonad.Actions.SinkAll.png XMonad.Layout.Spiral_collapsed.png XMonad.Actions.Submap_collapsed.png XMonad.Layout.Spiral_core.png XMonad.Actions.Submap.png XMonad.Layout.Spiral.png XMonad.Actions.SwapWorkspaces_collapsed.png XMonad.Layout.Square_collapsed.png XMonad.Actions.SwapWorkspaces.png XMonad.Layout.Square.png XMonad.Actions.TagWindows_collapsed.png XMonad.Layout.TabBarDecoration_collapsed.png XMonad.Actions.TagWindows.png XMonad.Layout.TabBarDecoration.png XMonad.Actions.UpdatePointer_collapsed.png XMonad.Layout.Tabbed_collapsed.png XMonad.Actions.UpdatePointer.png XMonad.Layout.Tabbed.png XMonad.Actions.Warp_collapsed.png XMonad.Layout.ToggleLayouts_collapsed.png XMonad.Actions.Warp.png XMonad.Layout.ToggleLayouts.png XMonad.Actions.WindowBringer_collapsed.png XMonad.Layout.TwoPane_collapsed.png XMonad.Actions.WindowBringer.png XMonad.Layout.TwoPane.png XMonad.Actions.WindowGo_collapsed.png XMonad.Layout.WindowArranger_collapsed.png XMonad.Actions.WindowGo.png XMonad.Layout.WindowArranger.png XMonad.Actions.WindowNavigation_collapsed.png XMonad.Layout.WindowNavigation_collapsed.png XMonad.Actions.WindowNavigation_core.png XMonad.Layout.WindowNavigation_core.png XMonad.Actions.WindowNavigation.png XMonad.Layout.WindowNavigation.png XMonad.Config.Arossato_collapsed.png XMonad.Layout.WorkspaceDir_collapsed.png XMonad.Config.Arossato.png XMonad.Layout.WorkspaceDir.png XMonad.Config.Azerty_collapsed.png XMonad.Prompt.AppendFile_collapsed.png XMonad.Config.Azerty.png XMonad.Prompt.AppendFile.png XMonad.Config.Desktop_collapsed.png XMonad.Prompt.AppLauncher_collapsed.png XMonad.Config.Desktop.png XMonad.Prompt.AppLauncher.png XMonad.Config.Droundy_collapsed.png XMonad.Prompt_collapsed.png XMonad.Config.Droundy.png XMonad.Prompt_core.png XMonad.Config.Gnome_collapsed.png XMonad.Prompt.Directory_collapsed.png XMonad.Config.Gnome.png XMonad.Prompt.Directory.png XMonad.Config.Kde_collapsed.png XMonad.Prompt.DirExec_collapsed.png XMonad.Config.Kde.png XMonad.Prompt.DirExec.png XMonad.Config.PlainConfig_collapsed.png XMonad.Prompt.Email_collapsed.png XMonad.Config.PlainConfig_core.png XMonad.Prompt.Email.png XMonad.Config.PlainConfig.png XMonad.Prompt.Input_collapsed.png XMonad.Config.Sjanssen_collapsed.png XMonad.Prompt.Input.png XMonad.Config.Sjanssen.png XMonad.Prompt.Layout_collapsed.png XMonad.Config.Xfce_collapsed.png XMonad.Prompt.Layout.png XMonad.Config.Xfce.png XMonad.Prompt.Man_collapsed.png xmonad-contrib.html XMonad.Prompt.Man.png XMonad.Doc_collapsed.png XMonad.Prompt.png XMonad.Doc.Configuring_collapsed.png XMonad.Prompt.RunOrRaise_collapsed.png XMonad.Doc.Configuring.png XMonad.Prompt.RunOrRaise.png XMonad.Doc.Developing_collapsed.png XMonad.Prompt.Shell_collapsed.png XMonad.Doc.Developing.png XMonad.Prompt.Shell_core.png XMonad.Doc.Extending_collapsed.png XMonad.Prompt.Shell.png XMonad.Doc.Extending.png XMonad.Prompt.Ssh_collapsed.png XMonad.Doc.png XMonad.Prompt.Ssh.png XMonad.Hooks.DynamicHooks_collapsed.png XMonad.Prompt.Theme_collapsed.png XMonad.Hooks.DynamicHooks.png XMonad.Prompt.Theme.png XMonad.Hooks.DynamicLog_collapsed.png XMonad.Prompt.Window_collapsed.png XMonad.Hooks.DynamicLog.png XMonad.Prompt.Window.png XMonad.Hooks.EventHook_collapsed.png XMonad.Prompt.Workspace_collapsed.png XMonad.Hooks.EventHook.png XMonad.Prompt.Workspace.png XMonad.Hooks.EwmhDesktops_collapsed.png XMonad.Prompt.XMonad_collapsed.png XMonad.Hooks.EwmhDesktops.png XMonad.Prompt.XMonad.png XMonad.Hooks.FadeInactive_collapsed.png XMonad.Util.CustomKeys_collapsed.png XMonad.Hooks.FadeInactive.png XMonad.Util.CustomKeys.png XMonad.Hooks.ManageDocks_collapsed.png XMonad.Util.Dmenu_collapsed.png XMonad.Hooks.ManageDocks.png XMonad.Util.Dmenu.png XMonad.Hooks.ManageHelpers_collapsed.png XMonad.Util.Dzen_collapsed.png XMonad.Hooks.ManageHelpers.png XMonad.Util.Dzen.png XMonad.Hooks.Script_collapsed.png XMonad.Util.EZConfig_collapsed.png XMonad.Hooks.Script.png XMonad.Util.EZConfig.png XMonad.Hooks.ServerMode_collapsed.png XMonad.Util.Invisible_collapsed.png XMonad.Hooks.ServerMode.png XMonad.Util.Invisible.png XMonad.Hooks.SetWMName_collapsed.png XMonad.Util.Loggers_collapsed.png XMonad.Hooks.SetWMName.png XMonad.Util.Loggers.png XMonad.Hooks.UrgencyHook_collapsed.png XMonad.Util.NamedWindows_collapsed.png XMonad.Hooks.UrgencyHook.png XMonad.Util.NamedWindows.png XMonad.Hooks.XPropManage_collapsed.png XMonad.Util.Paste_collapsed.png XMonad.Hooks.XPropManage.png XMonad.Util.Paste.png XMonad.Layout.Accordion_collapsed.png XMonad.Util.Run_collapsed.png XMonad.Layout.Accordion.png XMonad.Util.Run.png XMonad.Layout.BoringWindows_collapsed.png XMonad.Util.Scratchpad_collapsed.png XMonad.Layout.BoringWindows.png XMonad.Util.Scratchpad.png XMonad.Layout.Circle_collapsed.png XMonad.Util.Themes_collapsed.png XMonad.Layout.Circle.png XMonad.Util.Themes.png XMonad.Layout.Combo_collapsed.png XMonad.Util.Timer_collapsed.png XMonad.Layout.Combo.png XMonad.Util.Timer.png XMonad.Layout.Decoration_collapsed.png XMonad.Util.WindowProperties_collapsed.png XMonad.Layout.Decoration_core.png XMonad.Util.WindowProperties_core.png XMonad.Layout.DecorationMadness_collapsed.png XMonad.Util.WindowProperties.png XMonad.Layout.DecorationMadness.png XMonad.Util.WorkspaceCompare_collapsed.png XMonad.Layout.Decoration.png XMonad.Util.WorkspaceCompare.png XMonad.Layout.Dishes_collapsed.png XMonad.Util.XUtils_collapsed.png XMonad.Layout.Dishes.png XMonad.Util.XUtils.png gwern@craft:24374~/bin/XMonadContrib/SourceGraph>grep XSelection * [ 1:19PM] gwern@craft:24375~/bin/XMonadContrib/SourceGraph> (I'd attach the output, but even a gzipped tarball of SourceGraph/ is 8.2M, and someone complained about the last one which was only a few megabytes, so...) -- gwern SLBM TRW NSS 32 Poseidon blackjack global Aum enforcers Unit -------------- 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/attachments/20081012/51a7a931/attachment.bin From nr at cs.tufts.edu Sun Oct 12 13:38:05 2008 From: nr at cs.tufts.edu (Norman Ramsey) Date: Sun Oct 12 13:34:25 2008 Subject: [Haskell] Abusing quickcheck to check existential properties Message-ID: <20081012173805.9902A7881D7@homedog.cs.tufts.edu> I recently used QuickCheck to check on some calculations for image compression. (I love exact rational arithmetic!) But I thought only to check for inverse properties, and I realized afterward I had failed to check for ranges. For example I should have checked that boundedB block = -1 <= b && b <= 1 where Cos a b c d = cos_of_block block which turns out to be correct. But actually my calculations were wrong, and the real bounds on b are not +/- 1 but rather +/- 0.5, so I might equally well have passed a more stringent test. It's quite embarrassing as I have only 5 bits of precision to represent b, and throwing away a bit on values that don't exist is not the best idea I have had recently. What I would really like to do is write some combinators for interval checking that say * It is a *universal* property that for *every* input, the output lies within the stated interval. * It is an *existential* property of *some* input that the output lies close to the ends of the stated interval. But how do I use QuickCheck to check an existential? I realize I could run boundsNotAchieved block = -0.9 <= b && b <= 0.9 where Cos a b c d = cos_of_block block and then if the test of boundsNotAcheived fails, my test passes (by exists x : P(x) iff not forall(x) : not P(x)). But if I set up a test suite in which some tests are supposed to fail and others are supposed to succeed, I will never keep track of which is which. I would like to build an existential test. Is it sufficient for me to write boundsAchieved block = expectFailure (-0.9 <= b && b <= 0.9) where Cos a b c d = cos_of_block block and then run 'quickCheck boundsAchieved'? In the long run I'd love something like fillsIntervalWithin :: (Num a, Ord a, Arbitrary a) => (a, a) -> a -> a -> Property with the idea that I want to test the partial application fillsIntervalWithin (lo, hi) epsilon and have the test succeed if every input x satisfies lo <= x <= hi and if some input x satisfies not (lo + epsilon <= x <= hi - epsilon). I'm betting someone on this list has already thought about similar problems and can advise me. (Because I have yet to write the specialized instance declaration for Arbitrary that guarantees the numerical invariants of the inputs, I have yet to test any of the examples in this email.) Norman From ivan.miljenovic at gmail.com Sun Oct 12 19:01:42 2008 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Sun Oct 12 18:58:04 2008 Subject: [Haskell] ANNOUNCE: Graphalyze-0.4 and SourceGraph-0.2 In-Reply-To: <20081012172440.GA4207@craft> References: <20081012235444.18600479@gmail.com> <20081012172440.GA4207@craft> Message-ID: <20081013090142.53945642@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 12 Oct 2008 13:24:40 -0400 Gwern Branwen wrote: > > However, I happened to want to look at the output for one of my modules, > XMonad.Util.XSelection - and it simply isn't there. Most of the XMC modules > seem to be there, but that one isn't. It's in the cabal file, SourceGraph did > not output any errors or warnings, but XSelection is not mentioned in the > HTML output nor are any PNGs generated with regard to it. See: Hmmmm..... that means that SourceGraph isn't able to parse it and dies silently. I'll have a look at myself later and try to find out why. - -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjygdoACgkQfEfFJ9JhvyigPACfejpPr5vYnSOxCFg6DQTfnk2U cpIAnAhh7fzI9OtzPAXYxPpDg66UZzeD =upq7 -----END PGP SIGNATURE----- From gwern0 at gmail.com Sun Oct 12 20:01:32 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Oct 12 19:58:13 2008 Subject: [Haskell] ANNOUNCE: Graphalyze-0.4 and SourceGraph-0.2 In-Reply-To: <20081013090142.53945642@gmail.com> References: <20081012235444.18600479@gmail.com> <20081012172440.GA4207@craft> <20081013090142.53945642@gmail.com> Message-ID: <20081013000132.GA28043@craft> On 2008.10.13 09:01:42 +1000, Ivan Lazar Miljenovic scribbled 1.3K characters: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sun, 12 Oct 2008 13:24:40 -0400 > Gwern Branwen wrote: > > > > However, I happened to want to look at the output for one of my modules, > > XMonad.Util.XSelection - and it simply isn't there. Most of the XMC modules > > seem to be there, but that one isn't. It's in the cabal file, SourceGraph did > > not output any errors or warnings, but XSelection is not mentioned in the > > HTML output nor are any PNGs generated with regard to it. See: > > Hmmmm..... that means that SourceGraph isn't able to parse it and dies > silently. I'll have a look at myself later and try to find out why. > > > - -- > Ivan Lazar Miljenovic 'K. So SourceGraph doesn't do any error reporting? I'll keep that in mind. -- gwern Trident Satellite Flu High mailbomb Competitor MCI SEAL NSRB PARKHILL -------------- 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/attachments/20081012/9015cb6e/attachment-0001.bin From ivan.miljenovic at gmail.com Mon Oct 13 03:10:15 2008 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon Oct 13 03:06:37 2008 Subject: [Haskell] ANNOUNCE: Graphalyze-0.4 and SourceGraph-0.2 In-Reply-To: <20081013000132.GA28043@craft> References: <20081012235444.18600479@gmail.com> <20081012172440.GA4207@craft> <20081013090142.53945642@gmail.com> <20081013000132.GA28043@craft> Message-ID: <20081013171015.07baa000@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 12 Oct 2008 20:01:32 -0400 Gwern Branwen wrote:> > 'K. So SourceGraph doesn't do any error reporting? I'll keep that in mind. In this case, it isn't SourceGraph's fault: Haskell-Src-Exts can't parse it. Maybe it doesn't parse CPP stuff properly? I'm not sure how I can get SourceGraph to parse files only after they've been pre-processed... The other option is that, once I've read the file and before I try parsing it, I do a bit of manual pre-processing of my own and simply filter out all lines that start with a '#' (i.e. remove all CPP annotations). The possible problem that I can think with this is that if there are two versions of a function foo defined within an #ifdef block, then that function will be listed twice (using nub might fix this but I'm not sure), or else if a function is optionally defined because you're not importing something (as appears to be the case with Gwern's XSelection module), then you have the situation where it's not possible to tell if it's using the external or internal one. - - -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjy9FoACgkQfEfFJ9Jhvyie+QCeOYA3MFoi41M+9PRC7F0KXPWL 3+0An2TsyRv26EO8a5AbdOGALzqHpYpD =/COZ -----END PGP SIGNATURE----- From koen at chalmers.se Mon Oct 13 05:57:17 2008 From: koen at chalmers.se (Koen Claessen) Date: Mon Oct 13 05:53:20 2008 Subject: [Haskell] Abusing quickcheck to check existential properties In-Reply-To: <20081012173805.9902A7881D7@homedog.cs.tufts.edu> References: <20081012173805.9902A7881D7@homedog.cs.tufts.edu> Message-ID: <1b30d3c80810130257y1f30cde1s9af3c6e6de24fac6@mail.gmail.com> Hi Norman, > But how do I use QuickCheck to check an existential? The "standard" method in QuickCheck is to be constructive, and actually implement the function that constructs for the value. So, instead of forAll x . exists y . P(x,y) you write forAll x . P(x, find_y(x)) for a suitably implemented function find_y. (This function is called a skolem function by logicians). It often depends on the problem domain how easy/hard it is to write such a function. For example, you may be actually able to just calculate y in find_y. Example: prop_Leq x (y :: Integer) = x <= y ==> exists d . d >= 0 s.t. x+d == y becomes prop_Leq x (y :: Integer) = x <= y ==> let d = y-x in d >= 0 && x+d == y In some cases though, some kind of search might be needed. The library SmallCheck provides default such search functions for Haskell types (if your search can be limited by a concept of depth). One thing that writing a skolem search function forces you to do is to decide when the existential can *not* be found (after all, we are interested in finding bugs). So, this forces you to think about what bounds you have on the search domain, which can be hard. /Koen From jakubuv at gmail.com Mon Oct 13 06:54:07 2008 From: jakubuv at gmail.com (Jan Jakubuv) Date: Mon Oct 13 06:50:12 2008 Subject: [Haskell] Could not deduce .. why ? In-Reply-To: <20081012153830.GA18606@gmx.de> References: <20081012153830.GA18606@gmx.de> Message-ID: hi, 2008/10/12 Marc Weber : > Surely I've overseen a small point. But I can't see it: > > class AddEl el_ el2_ elc_ where > addEl :: el_ -> elc -> el2_ -- el, child Did you mean "elc_" instead of "elc" in the type signature of addEl? jan. From genaim at clip.dia.fi.upm.es Mon Oct 13 16:18:51 2008 From: genaim at clip.dia.fi.upm.es (Samir Genaim) Date: Mon Oct 13 16:15:14 2008 Subject: [Haskell] BYTECODE09: 2nd Call for Papers Message-ID: ******************************************************** * 2nd Call for Papers * * * * Fourth Workshop on Bytecode Semantics, * * Verification, Analysis and Transformation * * * * York, UK, 29th March 2009, part of ETAPS 2009 * * * * Venue: The University of York * * * * http://www.clip.dia.fi.upm.es/Conferences/BYTECODE09 * * * ******************************************************** Important Dates =============== Paper Submission December 21, 2008 Notification January 25, 2009 Final Version February 8, 2009 Workshop March 29, 2009 Workshop Description ==================== Bytecode, such as produced by e.g. .Net and Java compilers, has become an important topic of interest, both for industry and academia. The industrial interest stems from the fact that bytecode is typically used for the Internet and mobile devices (smartcards, phones, etc.), where security is a major issue. Moreover, bytecode is device-independent and allows dynamic loading of classes, which provides an extra challenge for the application of formal methods. In addition, the lack of structure of the code and the pervasive presence of the operand stack also provide extra challenges for the analysis of bytecode. This workshop will focus on the latest developments in the semantics, verification, analysis, and transformation of bytecode. Both new theoretical results and tool demonstrations are welcome. Invited Speaker =============== TBA Submission ========== There are two paper categories, Regular and Tool demo papers. Paper should be written using the ENTCS style and submitted through the easy chair page "http://www.easychair.org/conferences/?conf=bytecode09". Please indicate in the submission page the category of your submission. Submissions will be evaluated by the Program Committee for inclusion in the ENTCS proceedings. Regular research papers should be at most 15 pages (including bibliography and excluding well-marked appendices not intended for publication). They must contain original contributions, be written in English and be unpublished and not submitted simultaneously for publication elsewhere. Tool demo papers must describe a completed, robust and well-documented tool -- highlighting the overall functionality of the tool, the interfaces of the tool, interesting examples and applications of the tool, an assessment of the tool's strengths and weaknesses, and a summary of documentation/support available with the tool. The body of the paper must be no longer than 6 pages in length (including bibliography), and it should give an overview of the tool, the methodology associated with its use, a summary of how the tool has been applied and to what effect, and it should indicate what supporting artifacts (user manual, example repository, downloads, etc) are available. This material will be included in the ENTCS proceedings if the paper is accepted. In addition, the paper should include an appendix (limited to six pages) that gives an outline of the proposed demo presentation (this material will NOT appear in the ENTCS proceedings). Program Committee ================= Wolfgang Ahrendt Chalmers University of Technology, SWE Elvira Albert (co-chair) Complutense University of Madrid, ESP June Andronick NICTA, AUS David Aspinall University of Edinburgh, UK Cristina Cifuentes Sun Microsystems, AUS Samir Genaim (co-chair) Technical University of Madrid, ESP Sara Kalvala The University of Warwick, UK Gerwin Klein The University of New South Wales, AUS Francesco Logozzo Microsoft Research, USA David Pichardie INRIA Rennes (IRISA), FRA Tamara Rezk INRIA-Microsoft, FRA Fausto Spoto University of Verona, ITA Eran Yahav IBM T.J. Watson Research Center, USA From nr at cs.tufts.edu Tue Oct 14 18:36:08 2008 From: nr at cs.tufts.edu (Norman Ramsey) Date: Tue Oct 14 18:32:07 2008 Subject: [Haskell] Abusing quickcheck to check existential properties In-Reply-To: <1b30d3c80810130257y1f30cde1s9af3c6e6de24fac6@mail.gmail.com> (sfid-H-20081013-060308-+80.77-1@multi.osbf.lua) References: <20081012173805.9902A7881D7@homedog.cs.tufts.edu> <1b30d3c80810130257y1f30cde1s9af3c6e6de24fac6@mail.gmail.com> (sfid-H-20081013-060308-+80.77-1@multi.osbf.lua) Message-ID: <20081014223608.5E637C06E@jindo.eecs.harvard.edu> > > But how do I use QuickCheck to check an existential? > > The "standard" method in QuickCheck is to be constructive, and > actually implement the function that constructs for the value. So, > instead of > > forAll x . exists y . P(x,y) > > you write > > forAll x . P(x, find_y(x)) Interesting. For A-E properties I can see where this approach would be helpful, especially if it's not too hard to think of a good skolem function. In my case x is empty and so I'm left with 'find a y such that P(y)' or a bit more exactly 'find an x in the four-dimensional unit cube such that 0.9 < f(x)' I've already written f and I'd really rather not write f-inverse; I want the computer to do some of the work for me. So perhaps SmallCheck would be a better way to go. It does seem a pity, as almost all the QuickCheck machinery would be useful in such a search. On the other hand there are similar scenarios on which I've already given up in despair, such as writing a generator for creating well-typed terms in a nontrivial language. Anyway, thanks for suggesting a skolem function---I'm sure I'll find use for one sooner or later. Norman From ekmett at gmail.com Tue Oct 14 19:34:29 2008 From: ekmett at gmail.com (Edward Kmett) Date: Tue Oct 14 19:30:29 2008 Subject: [Haskell] Abusing quickcheck to check existential properties In-Reply-To: <20081014223608.5E637C06E@jindo.eecs.harvard.edu> References: <20081012173805.9902A7881D7@homedog.cs.tufts.edu> <1b30d3c80810130257y1f30cde1s9af3c6e6de24fac6@mail.gmail.com> <20081014223608.5E637C06E@jindo.eecs.harvard.edu> Message-ID: <7fb8f82f0810141634j34f01367u7d9f3eb8ef4273c1@mail.gmail.com> The answer is that QuickCheck can't correctly constructively verify an existential condition without a constructive mechanism to generate the existential (i.e. the Skolem function mentioned before). If you think about it from a plausible reasoning and constructive logic sense, QuickCheck should not be able to answer the question you desire. After all it runs a bounded number of tests, if it didn't find your case in that number of checks its not definitive. It may have been looking in the wrong spots at the wrong cases. A QuickCheck merely provides support for the plausibility of a universally quantified statement, much like how an experiment can't prove a model in physics, it can merely provide support for it. (see Polya's Mathematics and Plausible Reasoning). The scientific method can never prove anything. QuickCheck never gives you a false negative, but that one-sided error dooms your quest. You can assert that something doesn't exist with QuickCheck, but asserting that something always holds is the domain of mathematics, not experiment, unless you can exhaustively enumerate the universe of discourse, which is why SmallCheck _can_ handle existential claims. Now that said, if you can strengthen the existential to a probabalistic claim about the odds of a random sample satisfying a given property are greater than some fixed known positive real number, then you can abuse the known QuickCheck sample size to say something about the odds of your 'expectFailure' style trick failing to substantiate your claim, but unfortunately this costs you the invariant that when quickcheck says something is wrong that something really is wrong. And to me at least the value of QuickCheck is that it never cries wolf. -Ed On Tue, Oct 14, 2008 at 6:36 PM, Norman Ramsey wrote: > > > But how do I use QuickCheck to check an existential? > > > > The "standard" method in QuickCheck is to be constructive, and > > actually implement the function that constructs for the value. So, > > instead of > > > > forAll x . exists y . P(x,y) > > > > you write > > > > forAll x . P(x, find_y(x)) > > > Interesting. For A-E properties I can see where this approach would > be helpful, especially if it's not too hard to think of a good skolem > function. In my case x is empty and so I'm left with > > 'find a y such that P(y)' > > or a bit more exactly > > 'find an x in the four-dimensional unit cube such that 0.9 < f(x)' > > I've already written f and I'd really rather not write f-inverse; > I want the computer to do some of the work for me. So perhaps > SmallCheck would be a better way to go. > > It does seem a pity, as almost all the QuickCheck machinery would be > useful in such a search. On the other hand there are similar > scenarios on which I've already given up in despair, such as writing a > generator for creating well-typed terms in a nontrivial language. > > Anyway, thanks for suggesting a skolem function---I'm sure I'll find > use for one sooner or later. > > > Norman > _______________________________________________ > 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/attachments/20081014/f774e86e/attachment-0001.htm From ben_moseley at mac.com Wed Oct 15 02:03:37 2008 From: ben_moseley at mac.com (Ben Moseley) Date: Wed Oct 15 01:59:53 2008 Subject: [Haskell] Abusing quickcheck to check existential properties In-Reply-To: <20081014223608.5E637C06E@jindo.eecs.harvard.edu> References: <20081012173805.9902A7881D7@homedog.cs.tufts.edu> <1b30d3c80810130257y1f30cde1s9af3c6e6de24fac6@mail.gmail.com> <20081014223608.5E637C06E@jindo.eecs.harvard.edu> Message-ID: <086F361B-63EB-4BA7-B2F4-489793EB487B@mac.com> > there are similar > scenarios on which I've already given up in despair, such as writing a > generator for creating well-typed terms in a nontrivial language. This is something I've also struggled with. I'm coming to the conclusion that it'd really be useful for the "Gen" monad to be parameterizable with some user state, or maybe even be made into a transformer. The only alternative really seems to be passing around the extra information manually between generator-creation functions, and this quickly gets to be a pain. For me this is probably the most serious short-coming of QuickCheck. --Ben On 14 Oct 2008, at 23:36, Norman Ramsey wrote: >>> But how do I use QuickCheck to check an existential? >> >> The "standard" method in QuickCheck is to be constructive, and >> actually implement the function that constructs for the value. So, >> instead of >> >> forAll x . exists y . P(x,y) >> >> you write >> >> forAll x . P(x, find_y(x)) > > > Interesting. For A-E properties I can see where this approach would > be helpful, especially if it's not too hard to think of a good skolem > function. In my case x is empty and so I'm left with > > 'find a y such that P(y)' > > or a bit more exactly > > 'find an x in the four-dimensional unit cube such that 0.9 < f(x)' > > I've already written f and I'd really rather not write f-inverse; > I want the computer to do some of the work for me. So perhaps > SmallCheck would be a better way to go. > > It does seem a pity, as almost all the QuickCheck machinery would be > useful in such a search. On the other hand there are similar > scenarios on which I've already given up in despair, such as writing a > generator for creating well-typed terms in a nontrivial language. > > Anyway, thanks for suggesting a skolem function---I'm sure I'll find > use for one sooner or later. > > > Norman > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From icfp.publicity at googlemail.com Wed Oct 15 10:17:34 2008 From: icfp.publicity at googlemail.com (Matthew Fluet (ICFP Publicity Chair)) Date: Wed Oct 15 10:13:42 2008 Subject: [Haskell] ICFP09: Call for Workshop Proposals Message-ID: <53ff55480810150717t7280c63endfd2a635454e761d@mail.gmail.com> CALL FOR WORKSHOP PROPOSALS ICFP 2009 14th ACM SIGPLAN International Conference on Functional Programming 31st August - 2nd September, 2009 Edinburgh, Scotland http://www.icfpconference.org/icfp2009 The 14th ACM SIGPLAN International Conference on Functional Programming will be held in Edinburgh, Scotland from 31st August to 2nd September 2009. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops to be affiliated with ICFP 2009 and sponsored by SIGPLAN. These workshops should be more informal and focused than ICFP itself, include sessions that enable interaction among the workshop attendees, and be fairly low cost. The preference is for one-day workshops, but other schedules can also be considered. The workshops themselves will be held between August 30th and September 5th, as capacity allows. ---------------------------------------------------------------------- Submission details Deadline for submission: 19th November 2008 Notification of acceptance: 17th December 2008 Prospective workshop organisers are invited to submit a completed workshop proposal form in plain text format to the ICFP 2009 workshop co-chairs (Chris Stone and Mike Sperber), via email to icfp09-workshops at cs.hmc.edu by 19th November 2008. Please note that this is a firm deadline. Organisers will be notified if their proposal is accepted by 17th December 2008, and if successful are required to produce a final report after the workshop has taken place that is suitable for publication in SIGPLAN Notices. The proposal form is available at: http://www.icfpconference.org/icfp2009/workshops/icfp09-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://acm.org/sigplan/sigplan_workshop_proposal.htm ---------------------------------------------------------------------- Selection committee The workshop proposals will be evaluated by a committee comprising the following members of the ICFP 2009 organising committee, together with the members of the SIGPLAN executive committee. Chris Stone Harvey Mudd College Workshops co-chair Mike Sperber DeinProgramm Workshops co-chair Graham Hutton University of Nottingham General Chair Andrew Tolmach Portland State University Program Chair ---------------------------------------------------------------------- Further information Any queries regarding ICFP 2009 workshop proposals should be addressed to the workshops co-chairs (Chris Stone and Mike Sperber), via email to icfp09-workshops at cs.hmc.edu From wiiat at kis-lab.com Fri Oct 17 04:02:01 2008 From: wiiat at kis-lab.com (WI-IAT'08) Date: Fri Oct 17 03:57:58 2008 Subject: [Haskell] Call for Participation: WI-IAT'08, Sydney, Australia Message-ID: <200810171602004213219@kis-lab.com> [Apologies if you receive this more than once] ====================== CALL FOR PARTICIPATION ====================== IEEE/WIC/ACM International Conference on Web Intelligence (WI'08) IEEE/WIC/ACM International Conference on Intelligent Agent Technology (IAT'08) December 9-12, 2008 Building 5, Haymarket Campus, University of Technology, Sydney, Australia http://www.lido.com.au/online/default.aspx?id=657fj3g91907# (see the map) Official: http://datamining.it.uts.edu.au/conferences/wi08/ http://datamining.it.uts.edu.au/conferences/iat08/ Sponsored and Organized by IEEE Computer Society Web Intelligence Consortium (WIC) Association for Computing Machinery (ACM) University of Technology, Sydney ================= HIGHLIGHTS ========================= 6 WI'08/IAT'08 Invited Speeches by Professor Edmund H. Durfee Professor Toru Ishida Professor Tsau Young Lin Professor Nigel Shadbolt Professor Yanchun Zhang Dr. Michael Witbrock 1 WIC Feature Talk by Professor Jiming Liu 4 Tutorials 16 WI-IAT Workshops Including the first WI-IAT Doctoral Workshop Presentations of Accepted Research Track Papers. The research track papers were selected from 651 submissions received from over 52 countries and regions. All main conference and workshop proceedings will be published in the conference proceedings by the IEEE Computer Society Press, indexed by EI. REGISTRATRION +++++++++++++ ********************************************** !!! Early-bird Registration by Nov 8, 2008 !!! ********************************************** On-line registration (and more information) at http://datamining.it.uts.edu.au/conferences/iat08/?page_id=45 Regular registration covers all the events of WI-IAT'08 during the four conference days including keynotes, tutorials, accepted paper presentations, and workshops, as well as includes proceedings for one of the conferences or its associated workshops. As usual, WI'08 and IAT'08 will be co-located, providing synergism among Web Intelligence and Intelligent Agent Technology. The two conferences will have a joint opening, invited talks, reception, and banquet. Attendees only need to register for one conference and can attend workshops, sessions, invited talks, panels and tutorials across the two conferences. INVITED TALKS +++++++++++++ WI'08/IAT'08 Joint Invited Talks include: Planning for Coordination and Coordination for Planning Professor Edmund H. Durfee EECS Department, University of Michigan, USA The Language Grid: Service-Oriented Collective Intelligence for Intercultural Collaboration Professor Toru Ishida Department of Social Informatics, Kyoto University, Japan The Emergence of Web Science Professor Nigel Shadbolt School of Electronics and Computer Science, University of Southampton, UK Knowledge Based Search Engine: Granular Computing on the Web Professor Tsau Young Lin Department of Computer Science, San Jose State University, USA Using Web Clustering for Web Community Mining and Analysis Professor Yanchun Zhang Centre for Applied Informatics Research, Victoria University, Australia Thinking Big - AI at Web Scale Dr. Michael Witbrock Vice President for Research at Cycorp, Inc., CEO of Cycorp Europe WIC FEATURE TALK ++++++++++++++++ Professor Jiming Liu Professor and Head of Computer Science Department, Hong Kong Baptist University TUTORIALS +++++++++ T1: Web Content Mining Vaclav Snasel Technical University of Ostrava, Czech Republic T2: Matching Words and Pictures: Problems, and Applications in the Web Latifur Khan University of Texas at Dallas, USA T3: Utilizing Federated Knowledge in Semantic Web Applications Jans Aasman Franz Inc. USA T4: Modeling Agent Organizations Virginia Dignum and Frank Dignum Utrecht University, The Netherlands WORKSHOPS +++++++++ W1: The 2nd Workshop on Collective Intelligence in Semantic Web and Social Networks (CISWSN 2008) W2: International Workshop on Web Information Retrieval Support Systems (WIRSS 2008) W3: International Workshop on Web Personalization, Reputation and Recommender Systems (WPRRS 2008) W4: International Workshop on Intelligent Web Interaction (IWI 2008) W5: Workshop on Intelligent e-Government (IEG 2008) W6: International Workshop on Fuzzy Logic On the Web (FLOW 2008) W7: Workshop on Natural Language Processing and Ontology Engineering (NLPOE 2008) W8: Workshop on Web Intelligence & Intelligent Agent Technology in eLearning (TUMAS-A 2008) W9: International Workshop on Computational Social Networks (IWCSN 2008) W10: Workshop on Optimization-based Data Mining and Web Intelligence (ODM 2008) W11: The Second International Workshop on Human Aspects in Ambient Intelligence: Agent Technology, Human-Oriented Knowledge and Applications (HAAI 2008) W12: International Workshop on E-Commerce, Business, and Services (ECBS 2008) W13: Workshop on P2P Computing and Autonomous Agents (P2P 2008) W14: International Workshop on Agents and Data Mining Interaction (ADMI 2008) W15: Workshop on Logics for Intelligent Agents and Multi-Agent Systems (WLIAMAS 2008) W16: 2008 WI-IAT Doctoral Workshop SOCIAL PROGRAM +++++++++++++++ The WI'08 and IAT'08 joint conference offers an exciting social programs, including the conference welcome reception on Dec. 10 and the conference banquet on Dec. 11. You can also enjoy the city of Sydney, including Darling Harbour and Opera House. You can get more information about the conference hotel and local information from the conference homepage: http://datamining.it.uts.edu.au/conferences/wi08/ CONTACT INFORMATION +++++++++++++++++++ A/Prof Longbing Cao Data Sciences & Knowledge Discovery Lab (the Smart Lab) Research Centre for Quantum Computation and Intelligent Systems University of Technology Sydney, Australia Office: +61-2-9514 4477 Fax: +61-2-9514 4517 E-mail: lbcao@it.uts.edu.au Homepage: www-staff.it.uts.edu.au/~lbcao The Smart Lab: datamining.it.uts.edu.au From frido at q-software-solutions.de Sat Oct 18 04:50:55 2008 From: frido at q-software-solutions.de (Friedrich) Date: Sat Oct 18 04:48:59 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell Message-ID: <87hc7a70cw.fsf@fvl.here> I've written just a few programs in Haskell one in a comparison for a task I had "nearly daily". The code analyzes Apache logs and picks some certain stuff from it and after that calculates a bit around with it. Here's the code module Main where import System import System.IO import System.Directory import System.IO.Error import Text.Regex import Control.Monad regexp = mkRegex ("([0-9]+) Windows ex") main = do files <- show_dir "[0-9].*" (sum,count) <- run_on_all_files (0,0) files let dd = (fromIntegral (sum::Integer))/ (fromIntegral (count::Int)) in putStr("Download = " ++ show sum ++ " in " ++ show count ++ " days are " ++ show dd ++ " downloads/day\n") run_on_all_files (a,b) [] = return (a,b) run_on_all_files (a,b) (x:xs) = do (s,c) <- run_on(a,b) x run_on_all_files (s,c) xs run_on (a,b) file_name = do handle <- openFile file_name ReadMode (sum,count) <- for_each_line (a,b) handle hClose handle return ((sum,count)) for_each_line (sum,count) handle = do l <- try (hGetLine handle) case l of Left err | isEOFError err -> return(sum,count) | otherwise -> ioError err Right line -> do let (nsum, ncount) = check_line line sum count for_each_line (nsum,ncount) handle check_line line sum count = let match = matchRegex regexp line in case match of Just strs -> (sum + read (head strs) :: Integer, count + 1) Nothing -> (sum, count) show_dir regmatch = do files <- getDirectoryContents "." let reg = mkRegex regmatch in return(filter (\file_name -> let fm = matchRegex reg file_name in case fm of Just strs -> True Nothing -> False) files) The point is this code works if there are just say a few files files to check. But it trashes my machine with around 1751 files. It sucks memory as wild and so it does not run as I think it should. I think I've overseen something which is bad written. Would you mind to tell me where I did "extraordinarily" bad. With best regards Friedrich From haskell at list.mightyreason.com Sat Oct 18 09:12:52 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Sat Oct 18 09:08:46 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <87hc7a70cw.fsf@fvl.here> References: <87hc7a70cw.fsf@fvl.here> Message-ID: <48F9E0D4.5000903@list.mightyreason.com> H mm.. The totals in "sum" and "count" are not computed until printed. This is too lazy. You start with '0' and (+) things to it, but never examine or force the value, so man many (+) thunks are built up in memory. If you use bang patterns then the change can be made here, to !sum !count: > check_line line !sum !count = > let match = matchRegex regexp line > in case match of > Just strs -> (sum + read (head strs) :: Integer, count + 1) > Nothing -> (sum, count) This will force evaluation before every check_line call. From byorgey at seas.upenn.edu Sat Oct 18 10:51:32 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Oct 18 10:47:31 2008 Subject: [Haskell] Haskell Weekly News: Issue 89 - October 18, 2008 Message-ID: <20081018145132.GA13307@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20081018 Issue 89 - October 18, 2008 --------------------------------------------------------------------------- Welcome to issue 89 of HWN, a newsletter covering developments in the [1]Haskell community. Announcements New Haskell tutorial. Miran Lipovaca (BONUS) has written a new and most excellent Haskell tutorial, [2]"Learn You a Haskell For Great Good!". Glob 0.1, globbing library. Matti Niemenmaa [3]announced the release of [4]Glob 0.1, a [5]small library for glob-matching purposes based on a subset of zsh's syntax. hledger 0.1, command-line accounting tool. Simon Michael [6]announced the [7]first release of [8]hledger, a command-line accounting tool similar to John Wiegley's c++ ledger. hledger generates simple ledger-compatible transaction and account balance reports from a plain text ledger file. [ANN] Haskell Cheatsheet v1.0. Justin Bailey [9]announced a [10]"cheat sheet" for Haskell, a PDF that tries to summarize Haskell 98's syntax, keywords and other language elements. Salsa: A .NET Bridge for Haskell. Andrew Appleyard [11]announced the [12]first release of [13]Salsa, an experimental Haskell library that allows Haskell programs to access .NET libraries. Salsa operates by loading the .NET runtime into your Haskell process and using the FFI (and run-time code generation) to marshall calls between the .NET and Haskell runtimes. It includes a code generator and a type-level library (which uses type families) to provide type-safe access to .NET libraries in Haskell with C#-style method overload resolution and implicit conversions. maccatcher-1.0.0. Jason Dusek [14]announced the [15]maccatcher package, which obtains a MAC address on *NIX and Windows. Call for Contributions - Haskell Communities and Activities Report, November 2008 edition. Janis Voigtlaender sent out [16]call for contributions to the 15th edition of the [17]Haskell Communities & Activities Report. The submission deadline is 31 October 2008. If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough -- please reconsider and submit an entry anyway! Data.IVar 0.1. Luke Palmer [18]announced the release of the [19]Data.IVar module, which provides write-once variables that can be blocked on in parallel. Unlike other implementations, Data.IVar does not use thread racing, since empirical tests have shown that the GHC scheduler is not quite good enough to handle thread-racing efficiently. A wiki page for managing the 6.10 handover. Don Stewart [20]announced a [21]wiki page to help with the transition to GHC 6.10. It collects the 7 or so known issues that break code with GHC 6.10. Please feel free to clean up, and especially add techniques for handling each change. GHC 6.10.1 RC 1. Ian Lynagh [22]announced [23]GHC 6.10.0.20081007, the first release candidate for GHC 6.10.1. There is also a [24]status page for GHC 6.10.1. Graphalyze-0.4 and SourceGraph-0.2. Ivan Lazar Miljenovic [25]announced the release of version 0.4 of the [26]Graphalyze library and version 0.2 of the [27]SourceGraph programme. SourceGraph is a programme designed to help you analyse the static complexity of your Haskell code when represented as a graph. These releases fix the bugs reported by Gwern Branwen, Magnus Therning, and Christopher Hinson. ListZipper-1.1.0.0. Ryan Ingram [28]announced the release of a simple list zipper library to Hackage, [29]ListZipper-1.1.0.0. darcs 2.1.0. Eric Kow [30]announced the release of [31]darcs 2.1.0. This version provides over 20 bug fixes and 7 new features since darcs 2.0.2. Most notably, the darcs-2 repository format is now the default, there is better HTTP support, and a longstanding 'pending patch' regression has been fixed. Yi 0.5.0.1. Jean-Phillipe Bernardy [32]announced the [33]0.5 release of Yi, a text editor written and extensible in Haskell. The long-term goal of the Yi project is to provide the editor of choice for Haskell programmers. Discussion OT: Haskell desktop wallpaper?. Magnus Therning [34]asked for Haskell-themed desktop wallpapers, and the community responded with quite a few nice images. Abusing quickcheck to check existential properties. Norman Ramsey [35]asked about using QuickCheck to check existential properties; suggestions involved SmallCheck and skolemization. Repair to floating point enumerations?. Malcolm Wallace began a [36]discussion on the merits of changing the (admittedly wonky) H98 [37]semantics for the Enum instances of Float and Double in Haskell Prime. A general question about the use of classes in defining interfaces. S. Doaitse Swierstra [38]asked about the feasibility of including top-level functions implemented using Applicative combinators as class methods with default implementations, to allow for the possibility of giving them more efficient implementations in specific instances. Proposal #2659: Add sortOn and friends to Data.List. Twan van Laarhoven [39]proposed adding sortOn (:: Ord b => (a -> b) -> [40]-> [a) and related functions to Data.List. Blog noise [41]Haskell news from the [42]blogosphere. * Andy Gill: [43]Pretty Printing Code with Markup. writes about a [44]new version of the HughesPJ pretty printing library which allows for pretty-printing with markup. * "FP Lunch": [45]Is purity inefficient?. Are idiomatic pure functional programs less efficient than idiomatic impure ones? * Eric Kow (kowey): [46]darcs weekly news #8. * Conal Elliott: [47]Composing memo tries. * Conal Elliott: [48]Elegant memoization with functional memo tries. * >>> Paolo Capriotti: [49]Monads for Markov chains. * Real-World Haskell: [50]Production status update: we're in QC1. * Joachim Breitner: [51]Infinite loops in Haskell. * Luke Palmer: [52]FRP Rant. * Luke Palmer: [53]data-memocombinators. * Bryan O'Sullivan: [54]Using Bloom filters for large scale gene sequence analysis in Haskell. Bryan and Ketil Malde's paper was accepted to PADL 09! * Arnar Birgisson: [55]Generating legal subsets of a dependency graph. * Creighton Hogg: [56]A silly example and a brief history. * >>> Robert Ottaway: [57]Sorting using Haskell. * Dan Piponi (sigfpe): [58]Untangling with Continued Fractions: part 5. * Holumbus: [59]Source Links Are Back!. * London Haskell Users Group: [60]Getting things going again. * >>> Justin Bailey: [61]The Haskell Cheatsheet. * >>> Nathan Sanders: [62]Type-directed programming. * >>> Micah Cowan: [63]Adventures in Haskell, Part 2: Kewlness. * Manuel M T Chakravarty: [64]GpuGen: Bringing the Power of GPUs to Haskell.. * >>> Binu Raghavan: [65]Haskell.... Binu is trying to learn Haskell. * Bjoern Edstroem: [66]Let's build an MP3-decoder!. Quotes of the Week * mckinna: you don't need to produce elements of an *arbitrary* whatever-it-is when you can produce elements of the *initial* whatever-it-is * tristes_tigres: thinks that programming languages can be divided into two broad classes: functional and dysfunctional * luqui: Down with the IO bourgeoisie! Long live the purely functional proletariat * ystael: it seems like every time i switch channels over to #haskell someone is talking about launching missiles. one might be inclined to draw freudian conclusions. About the Haskell Weekly News New editions are posted to [67]the Haskell mailing list as well as to [68]the Haskell Sequence and [69]Planet Haskell. [70]RSS is also available, and headlines appear on [71]haskell.org. To help create new editions of this newsletter, please see the information on [72]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [73]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://learnyouahaskell.com/ 3. http://article.gmane.org/gmane.comp.lang.haskell.cafe/46583 4. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Glob 5. http://iki.fi/matti.niemenmaa/glob/index.html 6. http://article.gmane.org/gmane.comp.lang.haskell.cafe/46461 7. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hledger 8. http://joyful.com/Ledger#hledger 9. http://article.gmane.org/gmane.comp.lang.haskell.cafe/46122 10. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/CheatSheet 11. http://article.gmane.org/gmane.comp.lang.haskell.cafe/46076 12. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Salsa 13. http://haskell.org/haskellwiki/Salsa 14. http://article.gmane.org/gmane.comp.lang.haskell.cafe/46072 15. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/maccatcher 16. http://article.gmane.org/gmane.comp.lang.haskell.cafe/45967 17. http://www.haskell.org/communities/ 18. http://article.gmane.org/gmane.comp.lang.haskell.cafe/45953 19. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/data-ivar 20. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/15442 21. http://haskell.org/haskellwiki/Upgrading_packages#Typical_breakages_with_GHC_6.10 22. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/15376 23. http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html 24. http://hackage.haskell.org/trac/ghc/wiki/GHC-6.10.1 25. http://article.gmane.org/gmane.comp.lang.haskell.general/16473 26. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Graphalyze 27. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SourceGraph 28. http://article.gmane.org/gmane.comp.lang.haskell.general/16468 29. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ListZipper 30. http://article.gmane.org/gmane.comp.lang.haskell.general/16465 31. http://darcs.net/darcs-2.1.0.tar.gz 32. http://www.haskell.org//pipermail/haskell/2008-October/020648.html 33. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/yi 34. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/45961 35. http://thread.gmane.org/gmane.comp.lang.haskell.general/16477 36. http://thread.gmane.org/gmane.comp.lang.haskell.prime/2678 37. http://haskell.org/onlinereport/basic.html#sect6.3.4 38. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/10206 39. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/10184 40. file://localhost/home/brent/haskell/hwn/a] 41. http://planet.haskell.org/ 42. http://haskell.org/haskellwiki/Blog_articles 43. http://blog.unsafeperformio.com/?p=31 44. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/marked%2Dpretty 45. http://sneezy.cs.nott.ac.uk/fplunch/weblog/?p=113 46. http://koweycode.blogspot.com/2008/10/darcs-weekly-news-8.html 47. http://feeds.feedburner.com/~r/conal/~3/422189172/ 48. http://feeds.feedburner.com/~r/conal/~3/422171822/ 49. http://pcapriotti.wordpress.com/2008/10/16/monads-for-markov-chains/ 50. http://www.realworldhaskell.org/blog/2008/10/15/production-status-update-were-in-qc1/ 51. https://www.joachim-breitner.de/blog/archives/308-Infinite-loops-in-Haskell.html 52. http://luqui.org/blog/archives/2008/10/15/frp-rant/ 53. http://luqui.org/blog/archives/2008/10/14/data-memocombinators/ 54. http://www.serpentine.com/blog/2008/09/28/using-bloom-filters-for-large-scale-gene-sequence-analysis-in-haskell/ 55. http://www.hvergi.net/2008/10/generating-legal-subsets-of-a-dependency-graph/ 56. http://abstractabsurd.blogspot.com/2008/10/silly-example-and-brief-history.html 57. http://tech-nickel.blogspot.com/2008/10/sorting-using-haskell.html 58. http://sigfpe.blogspot.com/2008/10/untangling-with-continued-fractions.html 59. http://holumbus.fh-wedel.de/blog/?p=15 60. http://www.londonhug.net/2008/10/11/getting-things-going-again/ 61. http://blog.codeslower.com/2008/10/The-Haskell-Cheatsheet 62. http://sandersn.com/blog/index.php?title=type_directed_programming 63. http://micah.cowan.name/2008/10/10/computers/software-development/adventures-in-haskell-part-2-kewlness/ 64. http://justtesting.org/post/53418059 65. http://variably-volatile.blogspot.com/2008/10/haskell.html 66. http://blog.bjrn.se/2008/10/lets-build-mp3-decoder.html 67. http://www.haskell.org/mailman/listinfo/haskell 68. http://sequence.complete.org/ 69. http://planet.haskell.org/ 70. http://sequence.complete.org/node/feed 71. http://haskell.org/ 72. http://haskell.org/haskellwiki/HWN 73. http://code.haskell.org/~byorgey/code/hwn/ From paul at cogito.org.uk Sat Oct 18 13:48:21 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Sat Oct 18 13:44:12 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <87hc7a70cw.fsf@fvl.here> References: <87hc7a70cw.fsf@fvl.here> Message-ID: <48FA2165.10709@cogito.org.uk> Friedrich wrote: > I've written just a few programs in Haskell one in a comparison for a > task I had "nearly daily". > The first thing I notice is that this is clearly a direct translation from something like Perl. Thats understandable, but I'd suggest rewriting it with something like this (untested, uncompiled code) -- Concatenate all the files into one big string. File reading is lazy, so this won't take all the memory. getAllFiles :: [String] -> IO String getAllFiles paths = do contents <- mapM getFile paths return $ concat contents Then use "lines" to split the result into individual lines and process them using "filter", "map" and "foldr". Because file reading is lazy, each line is only read when it is to be processed, and then gets reaped by the garbage collector. So it all runs in constant memory. (By the way, putting in the top level type declarations helps a lot when you make a mistake.) One thing you are doing right is keeping a (sum, count) pair. A gotcha with Haskell is to compute an average of a list of numbers like this: mean :: [Double] -> Double mean xs = sum xs / fromIntegral (length xs) The problem with this is that it has to traverse the list twice, which means that the whole list has to be held in memory. So instead you have to write something like: mean xs = let (total, count) = foldr (\x (t, c) -> (t + x, c+1)) (0.0, 0) xs in total / fromIntegral count This is a pain, but it does only traverse the list once. See how you get on. Paul. > The code analyzes Apache logs and picks some certain stuff from it and > after that calculates a bit around with it. > > Here's the code > module Main where > import System > import System.IO > import System.Directory > import System.IO.Error > import Text.Regex > import Control.Monad > > regexp = mkRegex ("([0-9]+) Windows ex") > > main = do > files <- show_dir "[0-9].*" > (sum,count) <- run_on_all_files (0,0) files > let dd = (fromIntegral (sum::Integer))/ (fromIntegral (count::Int)) > in > putStr("Download = " ++ show sum ++ " in " ++ show count ++ " days are " ++ show dd ++ " downloads/day\n") > > > > > run_on_all_files (a,b) [] = return (a,b) > run_on_all_files (a,b) (x:xs) = do (s,c) <- run_on(a,b) x > run_on_all_files (s,c) xs > > > run_on (a,b) file_name = do > handle <- openFile file_name ReadMode > (sum,count) <- for_each_line (a,b) handle > hClose handle > return ((sum,count)) > > for_each_line (sum,count) handle = do > l <- try (hGetLine handle) > case l of > Left err > | isEOFError err -> return(sum,count) > | otherwise -> ioError err > Right line -> do > let (nsum, ncount) = check_line line sum count > for_each_line (nsum,ncount) handle > > > > check_line line sum count = > let match = matchRegex regexp line > in case match of > Just strs -> (sum + read (head strs) :: Integer, count + 1) > Nothing -> (sum, count) > > > > > show_dir regmatch = do > files <- getDirectoryContents "." > let reg = mkRegex regmatch in > return(filter (\file_name -> let fm = matchRegex reg file_name > in case fm of > Just strs -> True > Nothing -> False) files) > > > The point is this code works if there are just say a few files > files to check. But it trashes my machine with around 1751 files. > > It sucks memory as wild and so it does not run as I think it should. > > I think I've overseen something which is bad written. Would you mind > to tell me where I did "extraordinarily" bad. > > With best regards > Friedrich > > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > From nr at cs.tufts.edu Sat Oct 18 18:39:32 2008 From: nr at cs.tufts.edu (Norman Ramsey) Date: Sat Oct 18 18:35:20 2008 Subject: [Haskell] Abusing quickcheck to check existential properties In-Reply-To: <7fb8f82f0810141634j34f01367u7d9f3eb8ef4273c1@mail.gmail.com> (sfid-H-20081014-194303-+104.96-1@multi.osbf.lua) References: <20081012173805.9902A7881D7@homedog.cs.tufts.edu> <1b30d3c80810130257y1f30cde1s9af3c6e6de24fac6@mail.gmail.com> <20081014223608.5E637C06E@jindo.eecs.harvard.edu> <7fb8f82f0810141634j34f01367u7d9f3eb8ef4273c1@mail.gmail.com> (sfid-H-20081014-194303-+104.96-1@multi.osbf.lua) Message-ID: <20081018223933.88124C06E@jindo.eecs.harvard.edu> > The answer is that QuickCheck can't correctly constructively verify an > existential condition without a constructive mechanism to generate the > existential (i.e. the Skolem function mentioned before). I agree but don't think it's relevant. QuickCheck can't verify a universal either. > If [elided] you can abuse [QuickCheck] but unfortunately this costs > you the invariant that when quickcheck says something is wrong that > something really is wrong. > > And to me at least the value of QuickCheck is that it never cries wolf. It's a great point, and I agree completely. I guess what I would like is to reuse most of the mechanisms in QuickCheck to have it say one of these two things: 1. Found an satisfying instance after 73 tries: [gives instance] 2. After 100 tries, could not find a satisfying instance. Like failure, the first tells you something definite about your program. And like passing 100 tests, the second tells you nothing. Norman From frido at q-software-solutions.de Sun Oct 19 02:07:53 2008 From: frido at q-software-solutions.de (Friedrich) Date: Sun Oct 19 02:05:55 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <56568580-F5CD-4270-BB6E-D5F06210B592@gmail.com> (Marshall Beddoe's message of "Sat, 18 Oct 2008 03:33:49 -0700") References: <87hc7a70cw.fsf@fvl.here> <56568580-F5CD-4270-BB6E-D5F06210B592@gmail.com> Message-ID: <87iqrp3yo6.fsf@fvl.here> Marshall Beddoe writes: > Also, read some chapters from here: > http://book.realworldhaskell.org/read/ > > Indispensable examples for writing higher performance log processing > code. I hope this book will soon be send out. I ordered my copy of course ;-) Howerver even if Strings are bad I can not see why they are hanging around so long. I open a file a read it line by line and I close the file so all read string are "garbage" and getting rid of them should not be that hard or should it? Regards Friedrich From frido at q-software-solutions.de Sun Oct 19 02:26:18 2008 From: frido at q-software-solutions.de (Friedrich) Date: Sun Oct 19 02:24:18 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <48FA2165.10709@cogito.org.uk> (Paul Johnson's message of "Sat, 18 Oct 2008 18:48:21 +0100") References: <87hc7a70cw.fsf@fvl.here> <48FA2165.10709@cogito.org.uk> Message-ID: <8763np3xth.fsf@fvl.here> Paul Johnson writes: > Friedrich wrote: >> I've written just a few programs in Haskell one in a comparison for a >> task I had "nearly daily". >> > The first thing I notice is that this is clearly a direct translation >> From something like Perl. Thats understandable, but I'd suggest > rewriting it with something like this (untested, uncompiled code) Quite a good match, however it was Bash and Awk. I implemente the same in C, Ocaml, Ruby, Tcl/Tk, Haskell, Smallltalk, Java, Common Lisp and IIRC C# ;-) > > -- Concatenate all the files into one big string. File reading is > lazy, so this won't take all the memory. > getAllFiles :: [String] -> IO String > getAllFiles paths = do > contents <- mapM getFile paths > return $ concat contents > > Then use "lines" to split the result into individual lines and process > them using "filter", "map" and "foldr". Because file reading is lazy, > each line is only read when it is to be processed, and then gets > reaped by the garbage collector. So it all runs in constant memory. Would you mind to elaborate a bit about it. What's so terrible to open one file after the other, reading it line by line and close the file thereafter. Of course it need memory during that but after the closing of the file the memory could be "freed". So what especially makes so much use of memory? > > (By the way, putting in the top level type declarations helps a lot > when you make a mistake.) Well I have my problems with that. Probably it comes from using Languages like Ruby and my special dislike of "typing things" comes especially from Java, C++ (well C is not "innocent" in that regard also. Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus From allbery at ece.cmu.edu Sun Oct 19 10:36:05 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Oct 19 10:31:51 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <87iqrp3yo6.fsf@fvl.here> References: <87hc7a70cw.fsf@fvl.here> <56568580-F5CD-4270-BB6E-D5F06210B592@gmail.com> <87iqrp3yo6.fsf@fvl.here> Message-ID: <707DB323-E4FE-4BE4-8572-8EA832FAB763@ece.cmu.edu> On 2008 Oct 19, at 2:07, Friedrich wrote: > Howerver even if Strings are bad I can not see why they are hanging > around so long. I open a file a read it line by line and I close the > file so all read string are "garbage" and getting rid of them should > not be that hard or should it? If your code is too lazy, you have the whole file + the close operation hanging around in unevaluated thunks until you print the result and it all gets processed all at once. Laziness is a double- edged sword. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Sun Oct 19 10:42:31 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Oct 19 10:38:16 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <8763np3xth.fsf@fvl.here> References: <87hc7a70cw.fsf@fvl.here> <48FA2165.10709@cogito.org.uk> <8763np3xth.fsf@fvl.here> Message-ID: <1E4003A1-2399-41C9-860E-A2D06C8400F3@ece.cmu.edu> On 2008 Oct 19, at 2:26, Friedrich wrote: > Paul Johnson writes: >>> (By the way, putting in the top level type declarations helps a lot >> when you make a mistake.) > Well I have my problems with that. Probably it comes from using > Languages like Ruby and my special dislike of "typing things" comes > especially from Java, C++ (well C is not "innocent" in that regard > also. Learn to love types: one of the neat things about Haskell is that if you can write down the type of a function then you have usually done 90% of the work of writing the code for it. Another is that in general, if you can't express the type of a function, it means you haven't thought through what you're trying to do. The relationship between types and proofs is especially obvious in Haskell. And proofs aren't merely mathematical entities, they're expressions of what you want to accomplish: if you can type your program, you have a high likelihood not only that it will compile, but that it will do what you intend. -- 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 frido at q-software-solutions.de Sun Oct 19 11:18:40 2008 From: frido at q-software-solutions.de (Friedrich) Date: Sun Oct 19 11:16:42 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <707DB323-E4FE-4BE4-8572-8EA832FAB763@ece.cmu.edu> (Brandon S. Allbery's message of "Sun, 19 Oct 2008 10:36:05 -0400") References: <87hc7a70cw.fsf@fvl.here> <56568580-F5CD-4270-BB6E-D5F06210B592@gmail.com> <87iqrp3yo6.fsf@fvl.here> <707DB323-E4FE-4BE4-8572-8EA832FAB763@ece.cmu.edu> Message-ID: <87bpxgy5nz.fsf@fvl.here> "Brandon S. Allbery KF8NH" writes: > On 2008 Oct 19, at 2:07, Friedrich wrote: >> Howerver even if Strings are bad I can not see why they are hanging >> around so long. I open a file a read it line by line and I close the >> file so all read string are "garbage" and getting rid of them should >> not be that hard or should it? > > > If your code is too lazy, you have the whole file + the close > operation hanging around in unevaluated thunks until you print the > result and it all gets processed all at once. Laziness is a double- > edged sword. Where in my code is this laziness hidden? Is it while recurions with sum and count? Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus From allbery at ece.cmu.edu Sun Oct 19 11:25:21 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Oct 19 11:21:07 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <87bpxgy5nz.fsf@fvl.here> References: <87hc7a70cw.fsf@fvl.here> <56568580-F5CD-4270-BB6E-D5F06210B592@gmail.com> <87iqrp3yo6.fsf@fvl.here> <707DB323-E4FE-4BE4-8572-8EA832FAB763@ece.cmu.edu> <87bpxgy5nz.fsf@fvl.here> Message-ID: <1B0148E8-44D9-4570-B5BF-3A9C34C1C4F0@ece.cmu.edu> On 2008 Oct 19, at 11:18, Friedrich wrote: > "Brandon S. Allbery KF8NH" writes: >> On 2008 Oct 19, at 2:07, Friedrich wrote: >>> Howerver even if Strings are bad I can not see why they are hanging >>> around so long. I open a file a read it line by line and I close the >>> file so all read string are "garbage" and getting rid of them should >>> not be that hard or should it? >> >> If your code is too lazy, you have the whole file + the close >> operation hanging around in unevaluated thunks until you print the >> result and it all gets processed all at once. Laziness is a double- >> edged sword. > Where in my code is this laziness hidden? Is it while recurions with > sum and count? That would be my guess, although I'd have to examine the Core (intermediate compilation stage) to be certain. Others here are better at looking at Haskell code and seeing where the laziness "leaks" are. -- 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 frido at q-software-solutions.de Sun Oct 19 11:24:15 2008 From: frido at q-software-solutions.de (Friedrich) Date: Sun Oct 19 11:22:16 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <1E4003A1-2399-41C9-860E-A2D06C8400F3@ece.cmu.edu> (Brandon S. Allbery's message of "Sun, 19 Oct 2008 10:42:31 -0400") References: <87hc7a70cw.fsf@fvl.here> <48FA2165.10709@cogito.org.uk> <8763np3xth.fsf@fvl.here> <1E4003A1-2399-41C9-860E-A2D06C8400F3@ece.cmu.edu> Message-ID: <877i84y5eo.fsf@fvl.here> "Brandon S. Allbery KF8NH" writes: > On 2008 Oct 19, at 2:26, Friedrich wrote: >> Paul Johnson writes: >>>> (By the way, putting in the top level type declarations helps a lot >>> when you make a mistake.) >> Well I have my problems with that. Probably it comes from using >> Languages like Ruby and my special dislike of "typing things" comes >> especially from Java, C++ (well C is not "innocent" in that regard >> also. > > Learn to love types: one of the neat things about Haskell is that if > you can write down the type of a function then you have usually done > 90% of the work of writing the code for it. Well I disagree. But that's another story. > Another is that in > general, if you can't express the type of a function, it means you > haven't thought through what you're trying to do. No that's not true. The use implies that. However I'm not advice resistant and will see if I use types. But IMHO that's should be job of the environment to figure out correctly and most of the time Haskell does "guess" right. And I surely can ask for the types. > The relationship > between types and proofs is especially obvious in Haskell. And proofs > aren't merely mathematical entities, they're expressions of what you > want to accomplish: if you can type your program, you have a high > likelihood not only that it will compile, but that it will do what you > intend. Well I could argue with the types in C and would not come along very far. In the TCP/IP stuff one can see what you have to do, sooner or later there is a cast... So I "betray" the type system... Or put more friendly and make me a "programming" hero. Hey compiler I know you got it but I'm right ;-) Unfortunatly this "beeing right" often is wishful thinking... -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus From frido at q-software-solutions.de Sun Oct 19 11:25:14 2008 From: frido at q-software-solutions.de (Friedrich) Date: Sun Oct 19 11:23:12 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <707DB323-E4FE-4BE4-8572-8EA832FAB763@ece.cmu.edu> (Brandon S. Allbery's message of "Sun, 19 Oct 2008 10:36:05 -0400") References: <87hc7a70cw.fsf@fvl.here> <56568580-F5CD-4270-BB6E-D5F06210B592@gmail.com> <87iqrp3yo6.fsf@fvl.here> <707DB323-E4FE-4BE4-8572-8EA832FAB763@ece.cmu.edu> Message-ID: <873aisy5d1.fsf@fvl.here> "Brandon S. Allbery KF8NH" writes: > On 2008 Oct 19, at 2:07, Friedrich wrote: >> Howerver even if Strings are bad I can not see why they are hanging >> around so long. I open a file a read it line by line and I close the >> file so all read string are "garbage" and getting rid of them should >> not be that hard or should it? > > > If your code is too lazy, you have the whole file + the close > operation hanging around in unevaluated thunks until you print the > result and it all gets processed all at once. Laziness is a double- > edged sword. Ok to be more concrete is the laziness "hidden" here? check_line line sum count = let match = matchRegex regexp line in case match of Just strs -> (sum + read (head strs) :: Integer, count + 1) Nothing -> (sum, count) Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus From allbery at ece.cmu.edu Sun Oct 19 11:35:45 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Oct 19 11:31:30 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <877i84y5eo.fsf@fvl.here> References: <87hc7a70cw.fsf@fvl.here> <48FA2165.10709@cogito.org.uk> <8763np3xth.fsf@fvl.here> <1E4003A1-2399-41C9-860E-A2D06C8400F3@ece.cmu.edu> <877i84y5eo.fsf@fvl.here> Message-ID: <0E4E3B13-E0B5-4E42-9F73-813751169691@ece.cmu.edu> On 2008 Oct 19, at 11:24, Friedrich wrote: > "Brandon S. Allbery KF8NH" writes: >> The relationship >> between types and proofs is especially obvious in Haskell. And >> proofs >> aren't merely mathematical entities, they're expressions of what you >> want to accomplish: if you can type your program, you have a high >> likelihood not only that it will compile, but that it will do what >> you >> intend. > Well I could argue with the types in C and would not come along very > far. In the TCP/IP stuff one can see what you have to do, sooner or From a Haskell standpoint, C and Java are virtually untyped. If you want to see types => programs in action, play around with the @free and @djinn commands in lambdabot (a Haskell bot that lives on FreeNode). @free treats a type as a theorem and produces a "proof" of it in Haskell code; @djinn takes a function declaration (type -> type) and generates the "obvious" code suggested by the declaration. (@djinn is sadly somewhat limited; it doesn't handle recursive types, so e.g. lists don't work too well.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Sun Oct 19 11:43:09 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Oct 19 11:38:55 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <873aisy5d1.fsf@fvl.here> References: <87hc7a70cw.fsf@fvl.here> <56568580-F5CD-4270-BB6E-D5F06210B592@gmail.com> <87iqrp3yo6.fsf@fvl.here> <707DB323-E4FE-4BE4-8572-8EA832FAB763@ece.cmu.edu> <873aisy5d1.fsf@fvl.here> Message-ID: <9B0DC289-01EF-444F-86B6-A4712302B4D5@ece.cmu.edu> On 2008 Oct 19, at 11:25, Friedrich wrote: > Ok to be more concrete is the laziness "hidden" here? > > check_line line sum count = > let match = matchRegex regexp line > in case match of > Just strs -> (sum + read (head strs) :: Integer, count > + 1) > Nothing -> (sum, count) For starters, "let" is lazy. "case" is strict to the extent that it has to evaluate enough to decide if the result is Just or Nothing, but that's useless if the code leading up to its application is lazy. I don't know how lazy matchRegex is, if it is lazy enough then all that gets evaluated by the case is just enough to know if the result is Just or Nothing but not the value of "strs". (One obvious possibility is that it determines that there *are* strings, but not what they are.) Everything else is automatically lazy. So, unless the caller forces the result of this function, you are very likely to end up with a chain of partially evaluated matches that don't get resolved until the result is printed. -- 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 chrycheng at gmail.com Sun Oct 19 13:01:21 2008 From: chrycheng at gmail.com (Chry Cheng) Date: Sun Oct 19 12:57:19 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <707DB323-E4FE-4BE4-8572-8EA832FAB763@ece.cmu.edu> (Brandon S. Allbery's message of "Sun\, 19 Oct 2008 10\:36\:05 -0400") References: <87hc7a70cw.fsf@fvl.here> <56568580-F5CD-4270-BB6E-D5F06210B592@gmail.com> <87iqrp3yo6.fsf@fvl.here> <707DB323-E4FE-4BE4-8572-8EA832FAB763@ece.cmu.edu> Message-ID: "Brandon S. Allbery KF8NH" writes: > Laziness is a double-edged sword. Perhaps the following page from Haskell Wiki would serve to enlighten more: http://haskell.org/haskellwiki/Foldr_Foldl_Foldl%27? This really made it clear to me how laziness can sometimes be a bad thing. From till at informatik.uni-bremen.de Sun Oct 19 13:19:50 2008 From: till at informatik.uni-bremen.de (Till Mossakowski) Date: Sun Oct 19 13:15:34 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: References: <87hc7a70cw.fsf@fvl.here> <56568580-F5CD-4270-BB6E-D5F06210B592@gmail.com> <87iqrp3yo6.fsf@fvl.here> <707DB323-E4FE-4BE4-8572-8EA832FAB763@ece.cmu.edu> Message-ID: <48FB6C36.2070805@informatik.uni-bremen.de> Chry Cheng schrieb: > "Brandon S. Allbery KF8NH" writes: > >> Laziness is a double-edged sword. > > Perhaps the following page from Haskell Wiki would serve to enlighten > more: http://haskell.org/haskellwiki/Foldr_Foldl_Foldl%27? This > really made it clear to me how laziness can sometimes be a bad thing. A student of mine switch from Haskell to Java because of exactly these laziness problems - after he tried out to make the program stricter in various ways, but failed to remove the space leak. There should be an easy way of declaring a Haskell function (or, if that won't work, a whole module) to use strict evaluation only, without the need to manually insert seq and foldl' etc. everywhere (or even to change the structure of the code completely). Till Mossakowski From paul at cogito.org.uk Sun Oct 19 13:48:10 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Sun Oct 19 13:43:56 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <873aisy5d1.fsf@fvl.here> References: <87hc7a70cw.fsf@fvl.here> <56568580-F5CD-4270-BB6E-D5F06210B592@gmail.com> <87iqrp3yo6.fsf@fvl.here> <707DB323-E4FE-4BE4-8572-8EA832FAB763@ece.cmu.edu> <873aisy5d1.fsf@fvl.here> Message-ID: <48FB72DA.2000901@cogito.org.uk> Friedrich wrote: > > Ok to be more concrete is the laziness "hidden" here? > > check_line line sum count = > let match = matchRegex regexp line > in case match of > Just strs -> (sum + read (head strs) :: Integer, count + 1) > Nothing -> (sum, count) > > Probably. I would guess that "sum" and "count" are not being forced (i.e. evaluated) until the end of the computation, so instead of computing the result of "sum + read (head strs)" your program is just creating a thunk. Because this is in a loop, you wind up with a chain of thunks. Try putting turning the "Just" line into something like Just strs -> (seq sum $ sum + read (head strs) :: Integer, seq count $ count + 1) That would be my guess. But I could be wrong. Paul. From frido at q-software-solutions.de Mon Oct 20 01:37:09 2008 From: frido at q-software-solutions.de (Friedrich) Date: Mon Oct 20 01:35:09 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: (Taral's message of "Sun, 19 Oct 2008 12:04:25 -0700") References: <87hc7a70cw.fsf@fvl.here> Message-ID: <87fxmr25fe.fsf@fvl.here> Taral writes: > On Sat, Oct 18, 2008 at 1:50 AM, Friedrich > wrote: >> I've written just a few programs in Haskell one in a comparison for a >> task I had "nearly daily". >> >> The code analyzes Apache logs and picks some certain stuff from it and >> after that calculates a bit around with it. >> >> Here's the code > > Wow, talk about doing everything by hand. :) There are a lot of > utility functions that make your life easier. Try this: > > import Control.Monad > import Data.Char > import Data.List > import System.Directory > import System.IO > import Text.Regex > > main = do > allFiles <- getDirectoryContents "." > let files = filter (isDigit . head) allFiles > contents <- mapM readFile files > let (sum, count) = foldl' countDownloads (0,0) $ lines $ concat contents > putStr ("Download = " ++ show sum ++ " in " ++ show count ++ " days are " ++ > show (fromIntegral sum / fromIntegral count) ++ " downloads/day\n") > > match = matchRegex $ mkRegex "([0-9]+) Windows ex" > > countDownloads (s, c) l = > case match l of > Just [n] -> (s + read n, c + 1) > Nothing -> (s, c) > > Unfortunately, it doesn't solve your space leak. (I checked this via > core, but you can check it by testing it.) There's only one possible > lazy point left: > > countDownloads (s, c) l = Ok, I used that code and now I got: ./haskell_2 haskell_2: 8500: openFile: resource exhausted (Too many open files) Sorry, so I can not writ it down like that. So the above part with allFiles has to be modified to not exhaust the file descriptors. Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus From chris at eidhof.nl Mon Oct 20 02:39:15 2008 From: chris at eidhof.nl (Chris Eidhof) Date: Mon Oct 20 02:35:11 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <877i84y5eo.fsf@fvl.here> References: <87hc7a70cw.fsf@fvl.here> <48FA2165.10709@cogito.org.uk> <8763np3xth.fsf@fvl.here> <1E4003A1-2399-41C9-860E-A2D06C8400F3@ece.cmu.edu> <877i84y5eo.fsf@fvl.here> Message-ID: <80B7585C-1D2C-4712-BB1B-78D90E3C74F1@eidhof.nl> I think it might be more appropriate to move this discussion to haskell-cafe. On 19 okt 2008, at 17:24, Friedrich wrote: >> Learn to love types: one of the neat things about Haskell is that if >> you can write down the type of a function then you have usually done >> 90% of the work of writing the code for it. > Well I disagree. But that's another story. Well, it's definitely not true when you're starting out with Haskell. The thing is: once you start to think in types it does work like this. You just think: what do I need as my input and what's my output. That's what you write down as your type and you're almost done! It's very similar to test-driven development; the point with TDD is not so much about making sure your program is correct: the big win (for me) is that it helps you think about the design of your program. The same holds for types. > > >> Another is that in >> general, if you can't express the type of a function, it means you >> haven't thought through what you're trying to do. > > No that's not true. The use implies that. However I'm not advice > resistant and will see if I use types. But IMHO that's should be job > of the environment to figure out correctly and most of the time > Haskell does "guess" right. And I surely can ask for the types. I agree. However, sometimes, when things get really complex, you can't figure out a way to write down the code. That's when it can be handy to start out from the types and slowly work towards the definition. At first, you'll think that types are there to make your life harder. After a while, you'll start to love them and to be honest: I feel quite uncomfortable programming in an untyped language these days ;). -chris From jwlato at gmail.com Mon Oct 20 04:52:01 2008 From: jwlato at gmail.com (John Lato) Date: Mon Oct 20 04:47:43 2008 Subject: [Haskell] Re: Probably a trivial thing for people knowing Message-ID: <9979e72e0810200152u4dae31c3h46f9b9714be0e16b@mail.gmail.com> Friedrich wrote: > "Brandon S. Allbery KF8NH" writes: > >> On 2008 Oct 19, at 2:26, Friedrich wrote: >>> Paul Johnson writes: >>>>> (By the way, putting in the top level type declarations helps a lot >>>> when you make a mistake.) >>> Well I have my problems with that. Probably it comes from using >>> Languages like Ruby and my special dislike of "typing things" comes >>> especially from Java, C++ (well C is not "innocent" in that regard >>> also. >> >> Learn to love types: one of the neat things about Haskell is that if >> you can write down the type of a function then you have usually done >> 90% of the work of writing the code for it. > Well I disagree. But that's another story. > >> Another is that in >> general, if you can't express the type of a function, it means you >> haven't thought through what you're trying to do. > > No that's not true. The use implies that. However I'm not advice > resistant and will see if I use types. But IMHO that's should be job > of the environment to figure out correctly and most of the time > Haskell does "guess" right. And I surely can ask for the types. > It's true for people who use Haskell a lot. The reason is that Haskell types are fundamentally different from types in C (and related). I think it has to do with how you reason about a program's behavior. A well-designed Haskell program has types that are extremely well-suited to the problem domain, and as such the type often encapsulates everything you need to know about the function. John Lato From simonpj at microsoft.com Mon Oct 20 17:20:04 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Oct 20 17:14:52 2008 Subject: [Haskell] Functional programming job opening Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D76B9C334@EA-EXMSG-C334.europe.corp.microsoft.com> Folks Looking for a job in functional programming. Here's one (at Microsoft): http://members.microsoft.com/careers/search/details.aspx?JobID=E29D3886-A152-4D95-873D-8890EFB683AD&start=1&interval=10&SortCol=DatePosted "We are seeking an experienced software development engineer who has mastered C/C++ and/or C# development and is now learning or is already an expert using F# (or Haskell). Our platform's logic engine is written in F# and we expect F#'s use to extend into many other areas of the platform. ... A strong interest in functional programming is necessary and as is comfort with theory-based software system designs." Simon From u.stenzel at web.de Mon Oct 20 18:44:52 2008 From: u.stenzel at web.de (Udo Stenzel) Date: Mon Oct 20 20:26:43 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <48FB72DA.2000901@cogito.org.uk> References: <87hc7a70cw.fsf@fvl.here> <56568580-F5CD-4270-BB6E-D5F06210B592@gmail.com> <87iqrp3yo6.fsf@fvl.here> <707DB323-E4FE-4BE4-8572-8EA832FAB763@ece.cmu.edu> <873aisy5d1.fsf@fvl.here> <48FB72DA.2000901@cogito.org.uk> Message-ID: <20081020224452.GA5744@web.de> > Friedrich wrote: > >Ok to be more concrete is the laziness "hidden" here? > > > >check_line line sum count = > > let match = matchRegex regexp line > > in case match of > > Just strs -> (sum + read (head strs) :: Integer, count + 1) > > Nothing -> (sum, count) Yes, part of it. To see why, put yourself into the role of an evaluator for your program. An application of check_line will not be evaluated until necessary, and it becomes necessary only if the result is bound to a pattern (and that binding is needed for some reason). At that point, enough has to be evaluated to determine whether the result is actually a pair or bottom. So what will you do? The body of check_line is a case expression, so you need to sufficiently evaluate its scrutinee. You evaluate enough of matchRegex to see whether the result is Nothing or Just. Let's say it's Just. So you descent into the Just branch, and you see the result is a pair (and not bottom). The elements of the pair have not been evaluated, there was no need to. Also, the arguments to check_line have not been evaluated, except for line. You need to force the evaluation of the elements of the result pair whenever the pair itself is demanded, for example: > >check_line line sum count = > > let match = matchRegex regexp line > > in case match of > > Just strs -> ((,) $! (sum + read (head strs) :: Integer)) $! count + 1 > > Nothing -> ((,) $! sum) $! count) (The associativity of ($!) is inconvenient here. I want left-associative ($!). Actually, a strict pair type would be even more convenient here.) On recent GHC with bang-patterns, this short-cut works, too. It's not quite equivalent, because it will create unevaluated thunks, though they won't pile up: > >check_line line !sum !count = > > let match = matchRegex regexp line > > in case match of > > Just strs -> (sum + read (head strs) :: Integer, count + 1) > > Nothing -> (sum, count) Paul Johnson wrote: > Try putting turning the "Just" line into something like > > Just strs -> (seq sum $ sum + read (head strs) :: Integer, seq count > $ count + 1) This doesn't help. First of all, you don't "try putting" anything anywhere. Without understanding what's going on, you'll only create ugly code, bang your head against a wall and still end up with a space leak (been there, done that, bought the t-shirt). Instead, go through the evaluation by hand and/or use a heap profiler to guide you. Then put strictness annotations where needed (and only there). Putting seqs inside the pair is useless, because the problem is that nobody will look there to begin with. Applying seq to sum and count helps, if done outside the pair constructor, but is not quite right. You want the new sums to be evaluated strictly, and while making the function strict in its arguments helps, it stops one step too early. -Udo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20081021/a745bcb0/attachment.bin From u.stenzel at web.de Mon Oct 20 18:49:45 2008 From: u.stenzel at web.de (Udo Stenzel) Date: Mon Oct 20 20:27:02 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <87fxmr25fe.fsf@fvl.here> References: <87hc7a70cw.fsf@fvl.here> <87fxmr25fe.fsf@fvl.here> Message-ID: <20081020224945.GB5744@web.de> Friedrich wrote: > Taral writes: > > Wow, talk about doing everything by hand. :) There are a lot of > > utility functions that make your life easier. Try this: Given a strict pair, it should work: > > import Control.Monad > > import Data.Char > > import Data.List > > import System.Directory > > import System.IO > > import Text.Regex > > data Pair = Pair !Integer !Integer > > main = do > > allFiles <- getDirectoryContents "." > > let files = filter (isDigit . head) allFiles > > contents <- mapM readFile files > > let (sum, count) = foldl' countDownloads (0,0) $ lines $ concat contents let Pair sum count = foldl' countDownloads (Pair 0 0) $ lines $ concat contents > > putStr ("Download = " ++ show sum ++ " in " ++ show count ++ " days are " ++ > > show (fromIntegral sum / fromIntegral count) ++ " downloads/day\n") > > > > match = matchRegex $ mkRegex "([0-9]+) Windows ex" > > > > countDownloads (s, c) l = > > case match l of > > Just [n] -> (s + read n, c + 1) > > Nothing -> (s, c) countDownloads p@(Pair s c) l = case match l of Just [n] -> Pair (s + read n) (c + 1) Nothing -> p -Udo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20081021/b87e1ec0/attachment.bin From frido at q-software-solutions.de Tue Oct 21 01:04:23 2008 From: frido at q-software-solutions.de (Friedrich) Date: Tue Oct 21 01:02:20 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <20081020224945.GB5744@web.de> (Udo Stenzel's message of "Tue, 21 Oct 2008 00:49:45 +0200") References: <87hc7a70cw.fsf@fvl.here> <87fxmr25fe.fsf@fvl.here> <20081020224945.GB5744@web.de> Message-ID: <87k5c2pmi0.fsf@fvl.here> Thanks, I just figured out that I run out of file descriptors with reading them all at once. But I probably can try the countDownloads function. We'll see how that works. Regards Friedrich From frido at q-software-solutions.de Tue Oct 21 02:03:04 2008 From: frido at q-software-solutions.de (Friedrich) Date: Tue Oct 21 03:14:07 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <20081020224452.GA5744@web.de> (Udo Stenzel's message of "Tue, 21 Oct 2008 00:44:52 +0200") References: <87hc7a70cw.fsf@fvl.here> <56568580-F5CD-4270-BB6E-D5F06210B592@gmail.com> <87iqrp3yo6.fsf@fvl.here> <707DB323-E4FE-4BE4-8572-8EA832FAB763@ece.cmu.edu> <873aisy5d1.fsf@fvl.here> <48FB72DA.2000901@cogito.org.uk> <20081020224452.GA5744@web.de> Message-ID: <87vdvm4h9j.fsf@fvl.here> Udo Stenzel writes: >> Friedrich wrote: >> >Ok to be more concrete is the laziness "hidden" here? >> > >> >check_line line sum count = >> > let match = matchRegex regexp line >> > in case match of >> > Just strs -> (sum + read (head strs) :: Integer, count + 1) >> > Nothing -> (sum, count) > > Yes, part of it. To see why, put yourself into the role of an evaluator > for your program. An application of check_line will not be evaluated > until necessary, and it becomes necessary only if the result is bound to > a pattern (and that binding is needed for some reason). At that point, > enough has to be evaluated to determine whether the result is actually a > pair or bottom. > > So what will you do? The body of check_line is a case expression, so > you need to sufficiently evaluate its scrutinee. You evaluate enough of > matchRegex to see whether the result is Nothing or Just. Let's say it's > Just. So you descent into the Just branch, and you see the result is a > pair (and not bottom). The elements of the pair have not been > evaluated, there was no need to. Also, the arguments to check_line have > not been evaluated, except for line. > > You need to force the evaluation of the elements of the result pair > whenever the pair itself is demanded, for example: > >> >check_line line sum count = >> > let match = matchRegex regexp line >> > in case match of >> > Just strs -> ((,) $! (sum + read (head strs) :: Integer)) $! count + 1 >> > Nothing -> ((,) $! sum) $! count) > > (The associativity of ($!) is inconvenient here. I want > left-associative ($!). Actually, a strict pair type would be even more > convenient here.) > > On recent GHC with bang-patterns, this short-cut works, too. It's not > quite equivalent, because it will create unevaluated thunks, though they > won't pile up: > >> >check_line line !sum !count = >> > let match = matchRegex regexp line >> > in case match of >> > Just strs -> (sum + read (head strs) :: Integer, count + 1) >> > Nothing -> (sum, count) Ok, I followed the suggestions. Now I have the following code: module Main where import System import System.IO import System.Directory import System.IO.Error import Text.Regex import Control.Monad regexp = mkRegex ("([0-9]+) Windows ex") main = do files <- show_dir "[0-9].*" (sum,count) <- run_on_all_files (0,0) files let dd = (fromIntegral (sum::Integer))/ (fromIntegral (count::Int)) in putStr("Download = " ++ show sum ++ " in " ++ show count ++ " days are " ++ show dd ++ " downloads/day\n") run_on_all_files (a,b) [] = return (a,b) run_on_all_files (a,b) (x:xs) = do (s,c) <- run_on(a,b) x run_on_all_files (s,c) xs run_on (a,b) file_name = do handle <- openFile file_name ReadMode (sum,count) <- for_each_line (a,b) handle hClose handle return ((sum,count)) for_each_line (sum, count) handle = do l <- try (hGetLine handle) case l of Left err | isEOFError err -> return(sum,count) | otherwise -> ioError err Right line -> do let (nsum, ncount) = count_downloads line (sum, count) for_each_line (nsum,ncount) handle count_downloads line (!sum, !count) = let match = matchRegex regexp line in case match of Just strs -> (sum + read (head strs) :: Integer, count + 1) Nothing -> (sum, count) show_dir regmatch = do files <- getDirectoryContents "." let reg = mkRegex regmatch in return(filter (\file_name -> let fm = matchRegex reg file_name in case fm of Just strs -> True Nothing -> False) files) But it still sucks memor as wild and more or less crashes the system. So why's that than? Regards Friedrich From frido at q-software-solutions.de Tue Oct 21 03:18:04 2008 From: frido at q-software-solutions.de (Friedrich) Date: Tue Oct 21 03:16:01 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <20081020224452.GA5744@web.de> (Udo Stenzel's message of "Tue, 21 Oct 2008 00:44:52 +0200") References: <87hc7a70cw.fsf@fvl.here> <56568580-F5CD-4270-BB6E-D5F06210B592@gmail.com> <87iqrp3yo6.fsf@fvl.here> <707DB323-E4FE-4BE4-8572-8EA832FAB763@ece.cmu.edu> <873aisy5d1.fsf@fvl.here> <48FB72DA.2000901@cogito.org.uk> <20081020224452.GA5744@web.de> Message-ID: <87r66a4dsj.fsf@fvl.here> Udo Stenzel writes: >> Friedrich wrote: >> >Ok to be more concrete is the laziness "hidden" here? >> > >> >check_line line sum count = >> > let match = matchRegex regexp line >> > in case match of >> > Just strs -> (sum + read (head strs) :: Integer, count + 1) >> > Nothing -> (sum, count) > > Yes, part of it. To see why, put yourself into the role of an evaluator > for your program. An application of check_line will not be evaluated > until necessary, and it becomes necessary only if the result is bound to > a pattern (and that binding is needed for some reason). At that point, > enough has to be evaluated to determine whether the result is actually a > pair or bottom. > > So what will you do? The body of check_line is a case expression, so > you need to sufficiently evaluate its scrutinee. You evaluate enough of > matchRegex to see whether the result is Nothing or Just. Let's say it's > Just. So you descent into the Just branch, and you see the result is a > pair (and not bottom). The elements of the pair have not been > evaluated, there was no need to. Also, the arguments to check_line have > not been evaluated, except for line. > > You need to force the evaluation of the elements of the result pair > whenever the pair itself is demanded, for example: > >> >check_line line sum count = >> > let match = matchRegex regexp line >> > in case match of >> > Just strs -> ((,) $! (sum + read (head strs) :: Integer)) $! count + 1 >> > Nothing -> ((,) $! sum) $! count) > > (The associativity of ($!) is inconvenient here. I want > left-associative ($!). Actually, a strict pair type would be even more > convenient here.) > > On recent GHC with bang-patterns, this short-cut works, too. It's not > quite equivalent, because it will create unevaluated thunks, though they > won't pile up: > >> >check_line line !sum !count = >> > let match = matchRegex regexp line >> > in case match of >> > Just strs -> (sum + read (head strs) :: Integer, count + 1) >> > Nothing -> (sum, count) Ok, I followed the suggestions. Now I have the following code: module Main where import System import System.IO import System.Directory import System.IO.Error import Text.Regex import Control.Monad regexp = mkRegex ("([0-9]+) Windows ex") main = do files <- show_dir "[0-9].*" (sum,count) <- run_on_all_files (0,0) files let dd = (fromIntegral (sum::Integer))/ (fromIntegral (count::Int)) in putStr("Download = " ++ show sum ++ " in " ++ show count ++ " days are " ++ show dd ++ " downloads/day\n") run_on_all_files (a,b) [] = return (a,b) run_on_all_files (a,b) (x:xs) = do (s,c) <- run_on(a,b) x run_on_all_files (s,c) xs run_on (a,b) file_name = do handle <- openFile file_name ReadMode (sum,count) <- for_each_line (a,b) handle hClose handle return ((sum,count)) for_each_line (sum, count) handle = do l <- try (hGetLine handle) case l of Left err | isEOFError err -> return(sum,count) | otherwise -> ioError err Right line -> do let (nsum, ncount) = count_downloads line (sum, count) for_each_line (nsum,ncount) handle count_downloads line (!sum, !count) = let match = matchRegex regexp line in case match of Just strs -> (sum + read (head strs) :: Integer, count + 1) Nothing -> (sum, count) show_dir regmatch = do files <- getDirectoryContents "." let reg = mkRegex regmatch in return(filter (\file_name -> let fm = matchRegex reg file_name in case fm of Just strs -> True Nothing -> False) files) But it still sucks memor as wild and more or less crashes the system. So why's that than? Regards Friedrich From apfelmus at quantentunnel.de Tue Oct 21 04:52:03 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Tue Oct 21 04:47:59 2008 Subject: [Haskell] Re: Probably a trivial thing for people knowing Haskell In-Reply-To: <8763np3xth.fsf@fvl.here> References: <87hc7a70cw.fsf@fvl.here> <48FA2165.10709@cogito.org.uk> <8763np3xth.fsf@fvl.here> Message-ID: Friedrich wrote: > Paul Johnson writes: >> >> -- Concatenate all the files into one big string. File reading is >> lazy, so this won't take all the memory. >> getAllFiles :: [String] -> IO String >> getAllFiles paths = do >> contents <- mapM getFile paths >> return $ concat contents >> >> Then use "lines" to split the result into individual lines and process >> them using "filter", "map" and "foldr". Because file reading is lazy, >> each line is only read when it is to be processed, and then gets >> reaped by the garbage collector. So it all runs in constant memory. > > Would you mind to elaborate a bit about it. What's so terrible to open > one file after the other, reading it line by line and close the file > thereafter. It's not beautiful. Here's a more idiomatic version {-# LANGUAGE BangPatterns #-} module Main where import Control.Monad import System.Directory import Text.Regex import Data.List import Data.Maybe main = do files <- filter_reg "[0-9].*" `liftM` getDirectoryContents "." (sum,count) <- sumcount `liftM` mapM run_file files let dd = fromIntegral sum / fromIntegral count putStrLn $ "Download = " ++ show sum ++ " in " ++ show count ++ " days are " ++ show dd ++ " downloads/day" sumcount :: [(Integer,Int)] -> (Integer,Int) sumcount = foldl' (\(!s,!c) (ds,dc) -> (s+ds,c+dc)) (0,0) run_file name = (sumcount . map check_line . lines) `liftM` readFile' name readFile' name = unsafeInterleaveIO $ openFile name ReadMode >>= hGetContents regexp = mkRegex "([0-9]+) Windows ex" check_line line = case matchRegex regexp line of Just (s:_) -> (read s,1) Nothing -> (0,0) filter_reg pat = let reg = mkRegex pat in filter $ isJust . matchRegex reg It's much shorter and should run in constant memory as well. Regards, apfelmus From frido at q-software-solutions.de Tue Oct 21 06:10:49 2008 From: frido at q-software-solutions.de (Friedrich) Date: Tue Oct 21 06:08:49 2008 Subject: [Haskell] Re: Probably a trivial thing for people knowing Haskell In-Reply-To: (apfelmus@quantentunnel.de's message of "Tue, 21 Oct 2008 10:52:03 +0200") References: <87hc7a70cw.fsf@fvl.here> <48FA2165.10709@cogito.org.uk> <8763np3xth.fsf@fvl.here> Message-ID: <8763nm45sm.fsf@fvl.here> the posted codes runs in constant memory, so yes that make it possible that the stuff runs. That's really nice. Howerver the time is drastically bad Even the ruby solution need just check_downloads/check_downloads.rb . 1,25s user 0,06s system 99% cpu 1,322 total Here's the ruby code #!/usr/bin/ruby sum = 0; count = 0; if (ARGV[0]) then Dir.chdir(ARGV[0]) else Dir.chdir("Mail/Administration") end Dir["[0-9]*"].each { |file | fh = File.open(file) while line = fh.gets if line =~ /(\d+) Windows executable/ num = $1.to_i #log.printf("file_name = %s, num = %d\n", file, num); sum += num count += 1 end end fh.close } printf("%d downloads in %d days = %.2f downlaods/day", sum, count, Float(sum)/count) but the haskell solution: ./chk_dwlds 17,71s user 0,11s system 99% cpu 17,836 total Ruby is surely not the speed king of scripting languages, but what Haskell delivers is "way worse".... Howerver at least it doesn not crash any longer.... Regards Friedrich From ketil at malde.org Tue Oct 21 08:42:22 2008 From: ketil at malde.org (Ketil Malde) Date: Tue Oct 21 08:38:04 2008 Subject: [Haskell] Re: Probably a trivial thing for people knowing Haskell In-Reply-To: <8763nm45sm.fsf@fvl.here> (Friedrich's message of "Tue\, 21 Oct 2008 12\:10\:49 +0200") References: <87hc7a70cw.fsf@fvl.here> <48FA2165.10709@cogito.org.uk> <8763np3xth.fsf@fvl.here> <8763nm45sm.fsf@fvl.here> Message-ID: <87wsg286hd.fsf@malde.org> Friedrich writes: > Even the ruby solution need just > check_downloads/check_downloads.rb . 1,25s user 0,06s system 99% cpu > 1,322 total [...] > but the haskell solution: > ./chk_dwlds 17,71s user 0,11s system 99% cpu 17,836 total I'm very surprised to see this. Did you profile it to see what takes so long? -k -- If I haven't seen further, it is by standing in the footprints of giants From frido at q-software-solutions.de Tue Oct 21 09:04:26 2008 From: frido at q-software-solutions.de (Friedrich) Date: Tue Oct 21 09:02:26 2008 Subject: [Haskell] Re: Probably a trivial thing for people knowing Haskell In-Reply-To: <87wsg286hd.fsf@malde.org> (Ketil Malde's message of "Tue, 21 Oct 2008 14:42:22 +0200") References: <87hc7a70cw.fsf@fvl.here> <48FA2165.10709@cogito.org.uk> <8763np3xth.fsf@fvl.here> <8763nm45sm.fsf@fvl.here> <87wsg286hd.fsf@malde.org> Message-ID: <87prlu2j6t.fsf@fvl.here> Well I never have tried to profile here's my first try. I compiled with ghc --make -O -prof -auto-all chk_dwlds.hs I've run the program with: ./chk_dwlds \+RTS -p \-RTS and got this .prof file Tue Oct 21 15:01 2008 Time and Allocation Profiling Report (Final) chk_dwlds +RTS -p -RTS total time = 19.62 secs (981 ticks @ 20 ms) total alloc = 19,090,366,024 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc run_file Main 67.2 96.5 check_line Main 31.5 2.5 sumcount Main 1.3 1.0 individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc MAIN MAIN 1 0 0.0 0.0 100.0 100.0 main Main 238 1 0.0 0.0 100.0 100.0 sumcount Main 242 1 0.0 0.0 0.0 0.0 run_file Main 241 1764 67.2 96.5 100.0 100.0 check_line Main 244 1944781 31.5 2.5 31.5 2.5 sumcount Main 243 1764 1.3 1.0 1.3 1.0 main Main 247 0 0.0 0.0 0.0 0.0 filter_reg Main 248 0 0.0 0.0 0.0 0.0 CAF Main 232 10 0.0 0.0 0.0 0.0 check_line Main 246 2 0.0 0.0 0.0 0.0 regexp Main 245 1 0.0 0.0 0.0 0.0 main Main 239 0 0.0 0.0 0.0 0.0 filter_reg Main 240 2 0.0 0.0 0.0 0.0 CAF Text.Read.Lex 209 8 0.0 0.0 0.0 0.0 CAF GHC.Read 204 1 0.0 0.0 0.0 0.0 CAF GHC.Float 203 3 0.0 0.0 0.0 0.0 CAF GHC.Int 198 1 0.0 0.0 0.0 0.0 CAF GHC.Handle 184 7 0.0 0.0 0.0 0.0 CAF System.Posix.Internals 168 7 0.0 0.0 0.0 0.0 CAF System.Directory 125 1 0.0 0.0 0.0 0.0 Regards Friedrich From simonpj at microsoft.com Tue Oct 21 09:50:25 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Oct 21 09:46:03 2008 Subject: [Haskell] Probably a trivial thing for people knowing Haskell In-Reply-To: <87r66a4dsj.fsf@fvl.here> References: <87hc7a70cw.fsf@fvl.here> <56568580-F5CD-4270-BB6E-D5F06210B592@gmail.com> <87iqrp3yo6.fsf@fvl.here> <707DB323-E4FE-4BE4-8572-8EA832FAB763@ece.cmu.edu> <873aisy5d1.fsf@fvl.here> <48FB72DA.2000901@cogito.org.uk> <20081020224452.GA5744@web.de> <87r66a4dsj.fsf@fvl.here> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D76B9C727@EA-EXMSG-C334.europe.corp.microsoft.com> Folks, I wonder if this worthwhile thread could move from haskell@haskell.org to haskell-cafe@haskell.org? The main Haskell list, haskell@haskell.org, is a low-bandwidth list for discussion starters and announcements. The Haskell Cafe, by contrast, is a high-bandwidth list for detailed discussion. We don't want to force subscribers to the main Haskell list to unsubscribe. Thanks Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On | Behalf Of Friedrich | Sent: 21 October 2008 08:18 | To: haskell@haskell.org | Subject: Re: [Haskell] Probably a trivial thing for people knowing Haskell | | Udo Stenzel writes: | | >> Friedrich wrote: | >> >Ok to be more concrete is the laziness "hidden" here? | >> > | >> >check_line line sum count = | >> > let match = matchRegex regexp line | >> > in case match of | >> > Just strs -> (sum + read (head strs) :: Integer, count + | 1) | >> > Nothing -> (sum, count) | > | > Yes, part of it. To see why, put yourself into the role of an evaluator | > for your program. An application of check_line will not be evaluated | > until necessary, and it becomes necessary only if the result is bound to | > a pattern (and that binding is needed for some reason). At that point, | > enough has to be evaluated to determine whether the result is actually a | > pair or bottom. | > | > So what will you do? The body of check_line is a case expression, so | > you need to sufficiently evaluate its scrutinee. You evaluate enough of | > matchRegex to see whether the result is Nothing or Just. Let's say it's | > Just. So you descent into the Just branch, and you see the result is a | > pair (and not bottom). The elements of the pair have not been | > evaluated, there was no need to. Also, the arguments to check_line have | > not been evaluated, except for line. | > | > You need to force the evaluation of the elements of the result pair | > whenever the pair itself is demanded, for example: | > | >> >check_line line sum count = | >> > let match = matchRegex regexp line | >> > in case match of | >> > Just strs -> ((,) $! (sum + read (head strs) :: Integer)) | $! count + 1 | >> > Nothing -> ((,) $! sum) $! count) | > | > (The associativity of ($!) is inconvenient here. I want | > left-associative ($!). Actually, a strict pair type would be even more | > convenient here.) | > | > On recent GHC with bang-patterns, this short-cut works, too. It's not | > quite equivalent, because it will create unevaluated thunks, though they | > won't pile up: | > | >> >check_line line !sum !count = | >> > let match = matchRegex regexp line | >> > in case match of | >> > Just strs -> (sum + read (head strs) :: Integer, count + | 1) | >> > Nothing -> (sum, count) | | Ok, I followed the suggestions. Now I have the following code: | | module Main where | import System | import System.IO | import System.Directory | import System.IO.Error | import Text.Regex | import Control.Monad | | regexp = mkRegex ("([0-9]+) Windows ex") | | main = do | files <- show_dir "[0-9].*" | (sum,count) <- run_on_all_files (0,0) files | let dd = (fromIntegral (sum::Integer))/ (fromIntegral (count::Int)) | in | putStr("Download = " ++ show sum ++ " in " ++ show count ++ " | days are " ++ show dd ++ " downloads/day\n") | | | | | run_on_all_files (a,b) [] = return (a,b) | run_on_all_files (a,b) (x:xs) = do (s,c) <- run_on(a,b) x | run_on_all_files (s,c) xs | | | run_on (a,b) file_name = do | handle <- openFile file_name ReadMode | (sum,count) <- for_each_line (a,b) handle | hClose handle | return ((sum,count)) | | for_each_line (sum, count) handle = do | l <- try (hGetLine handle) | case l of | Left err | | isEOFError err -> return(sum,count) | | otherwise -> ioError err | Right line -> do | let (nsum, ncount) = | count_downloads line (sum, count) | for_each_line (nsum,ncount) | handle | | | | count_downloads line (!sum, !count) = | let match = matchRegex regexp line | in case match of | Just strs -> (sum + read (head strs) :: Integer, count + 1) | Nothing -> (sum, count) | | | | show_dir regmatch = do | files <- getDirectoryContents "." | let reg = mkRegex regmatch in | return(filter (\file_name -> let fm = | matchRegex reg file_name | in case fm of | Just strs -> True | Nothing -> False) files) | | | | | But it still sucks memor as wild and more or less crashes the | system. So why's that than? | | Regards | Friedrich | | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From voigt at tcs.inf.tu-dresden.de Tue Oct 21 10:11:50 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Tue Oct 21 10:07:40 2008 Subject: [Haskell] REMINDER: Haskell Communities and Activities Report Message-ID: <48FDE326.1010700@tcs.inf.tu-dresden.de> Dear Haskellers, The deadline for the November 2008 edition of the Haskell Communities and Activities Report is only ten days away. If you haven't already, please write an entry for your new project, or update your old entry. Please mail your entries to hcar@haskell.org in plain text or LaTeX format. More information can be found in the original Call for Contributions at: http://www.haskell.org/pipermail/haskell/2008-October/020651.html I look forward to receiving your contributions. Thanks a lot, Janis (current editor) -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From rickard.nilsson at telia.com Tue Oct 21 15:26:33 2008 From: rickard.nilsson at telia.com (Rickard Nilsson) Date: Tue Oct 21 15:22:15 2008 Subject: [Haskell] Abusing quickcheck to check existential properties In-Reply-To: <20081018223933.88124C06E@jindo.eecs.harvard.edu> References: <20081012173805.9902A7881D7@homedog.cs.tufts.edu> <1b30d3c80810130257y1f30cde1s9af3c6e6de24fac6@mail.gmail.com> <20081014223608.5E637C06E@jindo.eecs.harvard.edu> <7fb8f82f0810141634j34f01367u7d9f3eb8ef4273c1@mail.gmail.com> <20081018223933.88124C06E@jindo.eecs.harvard.edu> Message-ID: On Sun, 19 Oct 2008 00:39:32 +0200, Norman Ramsey wrote: > I guess what I would like is to reuse most of the mechanisms in > QuickCheck to have it say one of these two things: > > 1. Found an satisfying instance after 73 tries: [gives instance] > > 2. After 100 tries, could not find a satisfying instance. > > Like failure, the first tells you something definite about your > program. And like passing 100 tests, the second tells you nothing. In ScalaCheck (QuickCheck for Scala, www.scalacheck.org) there is an "exists" combinator which naively tries to find a value satisfying the property. So you can do the following: val p = exists(arbitrary[Int])( n => (n > 0) ==> (n+n == n*n) ) scala> p.check + OK, proved property. > ARG_0: "2" val q = exists(arbitrary[Int])( n => (n > 10) ==> (n+n == n*n) ) scala> q.check ! Gave up after only 0 passed tests. 500 tests were discarded. As you can see, there is a notion of proved properties in ScalaCheck, which was introduced to support the "exists" method. Of course, if the property is non-trivial ScalaCheck has a hard time finding a proof. Regards, Rickard Nilsson From roconnor at theorem.ca Tue Oct 21 20:12:05 2008 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Tue Oct 21 20:07:41 2008 Subject: [Haskell] ANNOUNCE: colour 0.0.0 Message-ID: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/colour-0.0.0 I hope for this library to become the standard colour library for Haskell. Most software does not properly blend colours because they fail to gamma-correct the colours before blending. Hopefully by using this library, Haskell programs dealing with colour blending will avoid this problem. I am making an early release of my colour library to get some feedback. I am especially interested in getting feedback on the interfaces: should functions be renamed, should functions be moved, etc. Should I put black and white colours into Data.Colour? Which is better form making a colour: (sRGB r g b) or (sRGB (r,g,b))? Bug reports and any patches are also welcome. Be warned, I haven't extensively tested this library yet. -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From colin at cs.york.ac.uk Wed Oct 22 05:38:59 2008 From: colin at cs.york.ac.uk (Colin Runciman) Date: Wed Oct 22 05:44:22 2008 Subject: [Haskell] Abusing quickcheck to check existential properties In-Reply-To: <20081018223933.88124C06E@jindo.eecs.harvard.edu> References: <20081012173805.9902A7881D7@homedog.cs.tufts.edu> <1b30d3c80810130257y1f30cde1s9af3c6e6de24fac6@mail.gmail.com> <20081014223608.5E637C06E@jindo.eecs.harvard.edu> <7fb8f82f0810141634j34f01367u7d9f3eb8ef4273c1@mail.gmail.com> (sfid-H-20081014-194303-+104.96-1@multi.osbf.lua) <20081018223933.88124C06E@jindo.eecs.harvard.edu> Message-ID: <48FEF4B3.3020802@cs.york.ac.uk> Norman, > I guess what I would like is to reuse most of the mechanisms in > QuickCheck to have it say one of these two things: > > 1. Found an satisfying instance after 73 tries: [gives instance] > > 2. After 100 tries, could not find a satisfying instance. > > Like failure, the first tells you something definite about your > program. And like passing 100 tests, the second tells you nothing. What you're asking for is similar to what SmallCheck could give you, but in the context of exhaustive testing of small values not sample testing of random values. However: 1. As most existentials are within the scope of a universal, there are many instances tested, so when a witness is indeed found nothing is reported. 2. A report is given only when no witness can be found within the specified search depth -- or when more than one can be found in the case of a unique existential. Perhaps your final remark is tongue-in-cheek? I agree the question of what "passed 100 tests" tells you is tricky; but it isn't "nothing". Anyway, in SmallCheck knowing that any witness could only be beyond the search depth does tell you something (eg. the expected witness might be a position in a list where the search depth is the length of the list). Colin R From nr at cs.tufts.edu Wed Oct 22 23:02:45 2008 From: nr at cs.tufts.edu (Norman Ramsey) Date: Wed Oct 22 22:58:19 2008 Subject: [Haskell] Abusing quickcheck to check existential properties In-Reply-To: <48FEF4B3.3020802@cs.york.ac.uk> (sfid-H-20081022-055309-+90.98-1@multi.osbf.lua) References: <20081012173805.9902A7881D7@homedog.cs.tufts.edu> <1b30d3c80810130257y1f30cde1s9af3c6e6de24fac6@mail.gmail.com> <20081014223608.5E637C06E@jindo.eecs.harvard.edu> <7fb8f82f0810141634j34f01367u7d9f3eb8ef4273c1@mail.gmail.com> (sfid-H-20081014-194303-+104.96-1@multi.osbf.lua) <20081018223933.88124C06E@jindo.eecs.harvard.edu> <48FEF4B3.3020802@cs.york.ac.uk> (sfid-H-20081022-055309-+90.98-1@multi.osbf.lua) Message-ID: <20081023030245.C53C9C06E@jindo.eecs.harvard.edu> > > I guess what I would like is to reuse most of the mechanisms in > > QuickCheck to have it say one of these two things: > > > > 1. Found an satisfying instance after 73 tries: [gives instance] > > > > 2. After 100 tries, could not find a satisfying instance. > > > > Like failure, the first tells you something definite about your > > program. And like passing 100 tests, the second tells you nothing. > > What you're asking for is similar to what SmallCheck could give you, but > in the context of exhaustive testing of small values not sample testing > of random values. However: > > 1. As most existentials are within the scope of a universal, there are > many instances tested, so when a witness is indeed found nothing is > reported. > > 2. A report is given only when no witness can be found within the > specified search depth -- or when more than one can be found in the case > of a unique existential. Exactly what I'm looking for. > Perhaps your final remark is tongue-in-cheek? Perhaps it's taken out of context :-) It was in a reply to Edward Kmett and was a copy of something Edward had said, with existentials exchanged for universals. I was aiming to make the point that if the inability to find a witness is not interesting, then the inability to find a counterexample is also not interesting. Since many of us may think we have learned something useful about a program when QuickCheck or SmallCheck fails to find a counterexample of a universal claim, perhaps we should reason contrapositively and agree that we have also learned something useful if QuickCheck or SmallCheck fails to find a witness of an existential claim. In other words, I was disagreeing with Edward. Way too subtly :-) > I agree the question of what "passed 100 tests" tells you is > tricky; but it isn't "nothing". I agree violently on both points :-) > Anyway, in SmallCheck knowing that any witness could only be beyond the > search depth does tell you something (eg. the expected witness might be > a position in a list where the search depth is the length of the list). Indeed so. Now if only I could find time to adapt QuickCheck and/or SmallCheck to generate unit tests for C code (I'm currently teaching C and assembly language) I would be one happy camper! Norman From dons at galois.com Thu Oct 23 10:25:26 2008 From: dons at galois.com (Don Stewart) Date: Thu Oct 23 10:20:47 2008 Subject: [Haskell] ANNOUNCE: colour 0.0.0 In-Reply-To: References: Message-ID: <20081023142526.GB793@scytale.galois.com> roconnor: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/colour-0.0.0 > > I hope for this library to become the standard colour library for Haskell. > Most software does not properly blend colours because they fail to > gamma-correct the colours before blending. Hopefully by using this > library, Haskell programs dealing with colour blending will avoid this > problem. > > I am making an early release of my colour library to get some feedback. I > am especially interested in getting feedback on the interfaces: should > functions be renamed, should functions be moved, etc. Should I put black > and white colours into Data.Colour? Which is better form making a colour: > (sRGB r g b) or (sRGB (r,g,b))? > > Bug reports and any patches are also welcome. Be warned, I haven't > extensively tested this library yet. > In Arch, http://aur.archlinux.org/packages.php?ID=20927 From marte at pms.informatik.uni-muenchen.de Thu Oct 23 15:56:18 2008 From: marte at pms.informatik.uni-muenchen.de (Michael Marte) Date: Thu Oct 23 15:51:54 2008 Subject: [Haskell] No fun with phantom types Message-ID: <200810232156.19080.marte@pms.informatik.uni-muenchen.de> Hello *, I am trying to extend the finite-domain (FD) constraint solver proposed by David Overton (http://overtond.blogspot.com/2008/07/pre.html) with arithmetic constraints by means of an embedded DSL. In principle, this is a very natural thing to do in a functional language; it is basically a matter of defining some suitable operators: data FDVar = FDVar Int deriving Show -- the type of FD variables data AExp = --the type of arithmetic expression over FD variables and integers ? ? IntegerConstant Int | ? ? Variable FDVar | ? ? Addition AExp AExp | ? ? Subtraction AExp AExp | ? ? Multiplication AExp AExp | ? ? IntegerDivision AExp AExp ? ? deriving Show infixl 7 #* ?-- multiplication infixl 7 #/ ?-- integer division infixl 6 #+ ?-- addition infixl 6 #- ?-- subtraction (#+), (#-), (#*), (#/) :: (MakeAExp a, MakeAExp b) => a -> b -> AExp (#+) = parseArgs Addition (#-) = parseArgs Subtraction (#*) = parseArgs Multiplication (#/) = parseArgs IntegerDivision with class MakeAExp a where ? ? makeAExp :: a -> AExp instance MakeAExp Int where ? ? makeAExp = IntegerConstant instance MakeAExp FDVar where ? ? makeAExp = Variable instance MakeAExp AExp where ? ? makeAExp = id parseArgs :: (MakeAExp a, MakeAExp b) => (AExp -> AExp -> c) -> a -> b -> c parseArgs f x y = f (makeAExp x) (makeAExp y) So far, so good. To avoid that FD variables escape their constraint stores, David employed a phantom type variable s leading to newtype FDVar s = FDVar { unFDVar :: Int } deriving (Ord, Eq) Trying to thread the phantom variable through my DSL implementation, I ended up with the following code: data AExp s = ? ? IntegerConstant Int | ? ? Variable (FDVar s) | ? ? Addition (AExp s) (AExp s) | ? ? Subtraction (AExp s) (AExp s) | ? ? Multiplication (AExp s) (AExp s) | ? ? IntegerDivision (AExp s) (AExp s) class MakeAExp a s where ? ? makeAExp :: a -> AExp s instance MakeAExp Int s where ? ? makeAExp = IntegerConstant instance MakeAExp (FDVar s) s where ? ? makeAExp x = Variable x instance MakeAExp (AExp s) s where ? ? makeAExp = id parseArgs :: (MakeAExp a s, MakeAExp b s) => (AExp s -> AExp s -> c s) -> a -> b -> c s parseArgs f x y = f (makeAExp x) (makeAExp y) infixl 7 #* ?-- multiplication infixl 7 #/ ?-- integer division infixl 6 #+ ?-- addition infixl 6 #- ?-- subtraction (#+), (#-), (#*), (#/) :: (MakeAExp a s, MakeAExp b s) => a -> b -> AExp s (#+) = parseArgs Addition (#-) = parseArgs Subtraction (#*) = parseArgs Multiplication (#/) = parseArgs IntegerDivision This code works if only one operator is applied: *FD> :type let x = (1::Int) in x #+ x let x = (1::Int) in x #+ x :: AExp s but *FD> :type let x = (1::Int) in x #+ x #+ x let x = (1::Int) in x #+ x #+ x :: (MakeAExp (AExp s) s1) => AExp s1 It appears to me that ghci generates two phantom types s and s1 and fails to unify them. Only the extensive use of type constraints seems to help like in the following example, where I used Int as phantom type: *FD> :type ((((1::Int) #+ (1::Int)) :: AExp Int) #+ (2::Int))::AExp Int ((((1::Int) #+ (1::Int)) :: AExp Int) #+ (2::Int))::AExp Int :: AExp Int But this approach only works on the command line and is out of question anyway. Any idea how to make my code work? I am using ghc 6.8.2 with {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE FlexibleInstances #-} Thanks, Michael From kr.angelov at gmail.com Thu Oct 23 16:26:33 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Thu Oct 23 16:22:04 2008 Subject: [Haskell] Current XML libraries status Message-ID: Hi, Does some one have made performance tests on the different XML libraries for Haskell? I have a 20MB xml file that I want to read. I remember from my earlier experiments (years ago) that all libraries were too slow and were consuming too much memory. I hoped that this situation had changed but maybe not. I looked at HaXML, libxml, HXML and HXT. HaXML eats a lot of memory and is still very slow. libxml is unfinished binding to the C library. Currently it only allows to create documents. HXML seems to be very promising. It works fast and it doesn't eat memory. Unfortunately it is that it seems to be rather old. It uses its own Arrow and Tree libraries instead of the standard libraries. I have not jumped into HXT yet because it seems to be very large library. Could someone recomend which one is the state of the art? Best Regards, Krasimir -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20081023/6aeeb905/attachment.htm From hpacheco at gmail.com Thu Oct 23 17:38:17 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Thu Oct 23 17:33:48 2008 Subject: [Haskell] Current XML libraries status In-Reply-To: References: Message-ID: <7b92c2840810231438q16c2d2daycc2f6d0ec2b2e4aa@mail.gmail.com> I remember that HaXML has also a lazy XML parser. maybe if you just need to use some specific information stored in your XML file you can earn some time/memory with it.From my experience, HXT seems faster. Cheers, hugo 2008/10/23 Krasimir Angelov > Hi, > > Does some one have made performance tests on the different XML libraries > for Haskell? I have a 20MB xml file that I want to read. I remember from my > earlier experiments (years ago) that all libraries were too slow and were > consuming too much memory. I hoped that this situation had changed but maybe > not. I looked at HaXML, libxml, HXML and HXT. HaXML eats a lot of memory and > is still very slow. libxml is unfinished binding to the C library. Currently > it only allows to create documents. HXML seems to be very promising. It > works fast and it doesn't eat memory. Unfortunately it is that it seems to > be rather old. It uses its own Arrow and Tree libraries instead of the > standard libraries. I have not jumped into HXT yet because it seems to be > very large library. Could someone recomend which one is the state of the > art? > > Best Regards, > Krasimir > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20081023/15af33a0/attachment.htm From ccshan at post.harvard.edu Thu Oct 23 18:44:06 2008 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Thu Oct 23 18:56:13 2008 Subject: [Haskell] Re: No fun with phantom types References: <200810232156.19080.marte@pms.informatik.uni-muenchen.de> Message-ID: Michael Marte wrote in article <200810232156.19080.marte@pms.informatik.uni-muenchen.de> in gmane.comp.lang.haskell.general: > *FD> :type let x = (1::Int) in x #+ x #+ x > let x = (1::Int) in x #+ x #+ x :: (MakeAExp (AExp s) s1) => AExp s1 > > It appears to me that ghci generates two phantom types s and s1 and fails to > unify them. Because you may define other MakeAExp instances elsewhere, ghc can't unify s and s1. For example, if you were to define instance MakeAExp (FDVar s) [s] ... instance MakeAExp (AExp [s]) s ... then s could be [s1] in your type! You can probably add functional dependencies to fix this problem, but I would suggest that you get rid of MakeAExp altogether. Just give (#+) and its friends the type "AExp s -> AExp s -> AExp s", with no type-class constraint. You need to explicitly inject FDVar into AExp, but most of the time you probably just need to handle AExp values without caring that they are constructed with Variable. You also need to inject Int into AExp, unless you simply make "instance Num (AExp s)". -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Lemonade was a popular drink and it still is. From donnie at darthik.com Thu Oct 23 19:09:59 2008 From: donnie at darthik.com (Donnie Jones) Date: Thu Oct 23 19:05:30 2008 Subject: [Haskell] Current XML libraries status In-Reply-To: References: Message-ID: Hello Krasimir, There is also the xml package from Galois: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml Hope that helps. __ Donnie 2008/10/23 Krasimir Angelov > Hi, > > Does some one have made performance tests on the different XML libraries > for Haskell? I have a 20MB xml file that I want to read. I remember from my > earlier experiments (years ago) that all libraries were too slow and were > consuming too much memory. I hoped that this situation had changed but maybe > not. I looked at HaXML, libxml, HXML and HXT. HaXML eats a lot of memory and > is still very slow. libxml is unfinished binding to the C library. Currently > it only allows to create documents. HXML seems to be very promising. It > works fast and it doesn't eat memory. Unfortunately it is that it seems to > be rather old. It uses its own Arrow and Tree libraries instead of the > standard libraries. I have not jumped into HXT yet because it seems to be > very large library. Could someone recomend which one is the state of the > art? > > Best Regards, > Krasimir > > > _______________________________________________ > 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/attachments/20081023/bc393ded/attachment.htm From david at overtons.id.au Thu Oct 23 19:17:07 2008 From: david at overtons.id.au (David Overton) Date: Thu Oct 23 19:12:38 2008 Subject: [Haskell] No fun with phantom types In-Reply-To: <200810232156.19080.marte@pms.informatik.uni-muenchen.de> References: <200810232156.19080.marte@pms.informatik.uni-muenchen.de> Message-ID: Hi Michael, You need a functional depenency in the class to make this work. Something like class MakeAExp a s | a -> s where makeAExp :: a -> AExp s should work, although I haven't tested it with your code. I did actually extend my FD constraint solver with arithmetic constraints myself, but I never got time to post it on my blog. It's also very inefficient at the moment, at least compared to the clp(fd) solver in GnuProlog. I took a slightly different approach to you. Instead of using an algebraic data type for expressions, I represent each node in the expression as a new FDVar in the constraint store. I've attached a copy of my code if you're interested. Let me know how you get on. David 2008/10/24 Michael Marte : > Hello *, > > I am trying to extend the finite-domain (FD) constraint solver proposed by > David Overton (http://overtond.blogspot.com/2008/07/pre.html) with arithmetic > constraints by means of an embedded DSL. In principle, this is a very natural > thing to do in a functional language; it is basically a matter of defining some > suitable operators: > > data FDVar = FDVar Int deriving Show -- the type of FD variables > > data AExp = --the type of arithmetic expression over FD variables and integers > IntegerConstant Int | > Variable FDVar | > Addition AExp AExp | > Subtraction AExp AExp | > Multiplication AExp AExp | > IntegerDivision AExp AExp > deriving Show > > infixl 7 #* -- multiplication > infixl 7 #/ -- integer division > > infixl 6 #+ -- addition > infixl 6 #- -- subtraction > > (#+), (#-), (#*), (#/) :: (MakeAExp a, MakeAExp b) => a -> b -> AExp > (#+) = parseArgs Addition > (#-) = parseArgs Subtraction > (#*) = parseArgs Multiplication > (#/) = parseArgs IntegerDivision > > with > > class MakeAExp a where > makeAExp :: a -> AExp > > instance MakeAExp Int where > makeAExp = IntegerConstant > > instance MakeAExp FDVar where > makeAExp = Variable > > instance MakeAExp AExp where > makeAExp = id > > parseArgs :: (MakeAExp a, MakeAExp b) => (AExp -> AExp -> c) -> a -> b -> c > parseArgs f x y = f (makeAExp x) (makeAExp y) > > So far, so good. > > To avoid that FD variables escape their constraint stores, David employed a > phantom type variable s leading to > > newtype FDVar s = FDVar { unFDVar :: Int } deriving (Ord, Eq) > > Trying to thread the phantom variable through my DSL implementation, I ended > up with the following code: > > data AExp s = > IntegerConstant Int | > Variable (FDVar s) | > Addition (AExp s) (AExp s) | > Subtraction (AExp s) (AExp s) | > Multiplication (AExp s) (AExp s) | > IntegerDivision (AExp s) (AExp s) > > class MakeAExp a s where > makeAExp :: a -> AExp s > > instance MakeAExp Int s where > makeAExp = IntegerConstant > > instance MakeAExp (FDVar s) s where > makeAExp x = Variable x > > instance MakeAExp (AExp s) s where > makeAExp = id > > parseArgs :: (MakeAExp a s, MakeAExp b s) => (AExp s -> AExp s -> c s) -> a -> b -> c s > parseArgs f x y = f (makeAExp x) (makeAExp y) > > infixl 7 #* -- multiplication > infixl 7 #/ -- integer division > > infixl 6 #+ -- addition > infixl 6 #- -- subtraction > > (#+), (#-), (#*), (#/) :: (MakeAExp a s, MakeAExp b s) => a -> b -> AExp s > (#+) = parseArgs Addition > (#-) = parseArgs Subtraction > (#*) = parseArgs Multiplication > (#/) = parseArgs IntegerDivision > > This code works if only one operator is applied: > > *FD> :type let x = (1::Int) in x #+ x > let x = (1::Int) in x #+ x :: AExp s > > but > > *FD> :type let x = (1::Int) in x #+ x #+ x > let x = (1::Int) in x #+ x #+ x :: (MakeAExp (AExp s) s1) => AExp s1 > > It appears to me that ghci generates two phantom types s and s1 and fails to > unify them. > > Only the extensive use of type constraints seems to help like in the following > example, where I used Int as phantom type: > > *FD> :type ((((1::Int) #+ (1::Int)) :: AExp Int) #+ (2::Int))::AExp Int > ((((1::Int) #+ (1::Int)) :: AExp Int) #+ (2::Int))::AExp Int :: AExp Int > > But this approach only works on the command line and is out of question > anyway. > > Any idea how to make my code work? > > I am using ghc 6.8.2 with > > {-# LANGUAGE GeneralizedNewtypeDeriving #-} > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE FlexibleInstances #-} > > > Thanks, > Michael > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -------------- next part -------------- A non-text attachment was scrubbed... Name: fd.tar.gz Type: application/x-gzip Size: 4659 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell/attachments/20081024/346e7b50/fd.tar-0001.bin From d at vidplace.com Thu Oct 23 20:18:05 2008 From: d at vidplace.com (David F. Place) Date: Thu Oct 23 20:13:39 2008 Subject: [Haskell] Current XML libraries status In-Reply-To: <7b92c2840810231438q16c2d2daycc2f6d0ec2b2e4aa@mail.gmail.com> References: <7b92c2840810231438q16c2d2daycc2f6d0ec2b2e4aa@mail.gmail.com> Message-ID: I've used HaXml's SAX parser to parse huge XML files. It is surprising that HXT doesn't seem to have a SAX parser as I understand that it is the successor to HaXml. DOM style parsing won't work with huge files. http://hackage.haskell.org/packages/archive/HaXml/1.19/doc/html/Text- XML-HaXml-SAX.html On Oct 23, 2008, at 11:38 PM, Hugo Pacheco wrote: > I remember that HaXML has also a lazy XML parser. maybe if you just > need to use some specific information stored in your XML file you > can earn some time/memory with it. > From my experience, HXT seems faster. > _____________ David F. Place d@vidplace.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20081024/73afd335/attachment.htm From micah at cowan.name Thu Oct 23 21:06:38 2008 From: micah at cowan.name (Micah Cowan) Date: Thu Oct 23 21:02:09 2008 Subject: [Haskell] Current XML libraries status In-Reply-To: References: <7b92c2840810231438q16c2d2daycc2f6d0ec2b2e4aa@mail.gmail.com> Message-ID: <49011F9E.4040801@cowan.name> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David F. Place wrote: > I've used HaXml's SAX parser to parse huge XML files. It is surprising > that HXT doesn't seem to have a SAX parser as I understand that it is > the successor to HaXml. DOM style parsing won't work with huge files. It can with a lazy processor, can't it? - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJAR+e7M8hyUobTrERAqBkAJ4hplduxSf0527c9XZRO63UXiS1KwCePlKa vJkCMBTDZeVmbwfzFaV4oIo= =TBNZ -----END PGP SIGNATURE----- From vpkaihla at gmail.com Fri Oct 24 02:57:17 2008 From: vpkaihla at gmail.com (Vesa Kaihlavirta) Date: Fri Oct 24 02:52:46 2008 Subject: [Haskell] Current XML libraries status In-Reply-To: References: Message-ID: <25acdd550810232357p478a46b6h27896f16e5323471@mail.gmail.com> 2008/10/24 Donnie Jones : > Hello Krasimir, > > There is also the xml package from Galois: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml That looks nice. Are there any examples of its usage? --vk From ketil at malde.org Fri Oct 24 03:31:34 2008 From: ketil at malde.org (Ketil Malde) Date: Fri Oct 24 03:27:05 2008 Subject: [Haskell] Current XML libraries status In-Reply-To: (Krasimir Angelov's message of "Thu\, 23 Oct 2008 22\:26\:33 +0200") References: Message-ID: <87zlkujvop.fsf@malde.org> "Krasimir Angelov" writes: > Does some one have made performance tests on the different XML libraries for > Haskell? I have a 20MB xml file that I want to read. I remember from my earlier > experiments (years ago) that all libraries were too slow and were consuming too > much memory. For my XML needs, I ended up just using the TagSoup library to extract the parts I wanted. At least this allows lazy processing of large files (a typical file is in the 1 to 4 GB range). Performance is acceptable, and Neil is rumored to have a plan to improve it further. -k -- If I haven't seen further, it is by standing in the footprints of giants From andres at cs.uu.nl Fri Oct 24 05:33:28 2008 From: andres at cs.uu.nl (Andres Loeh) Date: Fri Oct 24 05:28:58 2008 Subject: [Haskell] ANNOUNCE: lhs2tex-1.14 Message-ID: <20081024093328.GR8028@cs.uu.nl> lhs2TeX version 1.14 ==================== We are pleased to announce a new release of lhs2TeX, a preprocessor to generate LaTeX code from literate Haskell sources. lhs2TeX includes the following features: * Highly customized output. * Liberal parser -- no restriction to Haskell 98. * Generate multiple versions of a program or document from a single source. * Active documents: call Haskell to generate parts of the document (useful for papers on Haskell). * A manual explaining all the important aspects of lhs2TeX. Changes (w.r.t. lhs2TeX 1.13) ----------------------------- * Compatible with cabal-1.6; traditional configure/make installation should still work. * Unicode support. * Support for Agda's lexing rules (via --agda flag). * Minor bugfixes. Requirements and Download ------------------------- A source distribution is available from http://people.cs.uu.nl/andres/lhs2tex/ and, of course, via Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/lhs2tex Should work on all major platforms, but has mainly been tested on Linux. Binaries will be made available on request. You need a recent version of GHC (6.8.{2,3} are tested, older versions might work) to build lhs2TeX, and, of course, you need a TeX distribution to make use of lhs2TeX's output. The program includes a configuration that is suitable for use with LaTeX. In theory, there should be no problem to generate code for other TeX flavors, such as plainTeX or ConTeXt. Happy lhs2TeXing, Andres Loeh and Ralf Hinze -- Andres Loeh, Universiteit Utrecht mailto:andres@cs.uu.nl mailto:mail@andres-loeh.de http://www.andres-loeh.de From kr.angelov at gmail.com Fri Oct 24 05:49:11 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Fri Oct 24 05:44:40 2008 Subject: [Haskell] Re: Current XML libraries status In-Reply-To: References: Message-ID: Thanks to everyone who answered. HXML still seems to be the best for me. It is fast and it has good Arrow interface. It is also a small and simple library. I tried also HXT with this example: http://www.haskell.org/haskellwiki/HXT#Getting_started:_Hello_world_examples but it just died with out of memory. HXML just works. I have not tried the Light XML library because it doesn't provide Arrow interface. I updated HXML to use more stuff from the standard libraries. Now I can use the syntax sugar for arrows with it. Is the library maintained? Should I send a patch to someone? Best Regards, Krasimir On Thu, Oct 23, 2008 at 10:26 PM, Krasimir Angelov wrote: > Hi, > > Does some one have made performance tests on the different XML libraries > for Haskell? I have a 20MB xml file that I want to read. I remember from my > earlier experiments (years ago) that all libraries were too slow and were > consuming too much memory. I hoped that this situation had changed but maybe > not. I looked at HaXML, libxml, HXML and HXT. HaXML eats a lot of memory and > is still very slow. libxml is unfinished binding to the C library. Currently > it only allows to create documents. HXML seems to be very promising. It > works fast and it doesn't eat memory. Unfortunately it is that it seems to > be rather old. It uses its own Arrow and Tree libraries instead of the > standard libraries. I have not jumped into HXT yet because it seems to be > very large library. Could someone recomend which one is the state of the > art? > > Best Regards, > Krasimir > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20081024/ba43eaae/attachment.htm From si at fh-wedel.de Fri Oct 24 06:44:12 2008 From: si at fh-wedel.de (Uwe Schmidt) Date: Fri Oct 24 06:37:30 2008 Subject: [Haskell] Re: Current XML libraries status In-Reply-To: References: Message-ID: <200810241244.12681.si@fh-wedel.de> Hello Krasimir, > Thanks to everyone who answered. HXML still seems to be the best for me. It > is fast and it has good Arrow interface. It is also a small and simple > library. I tried also HXT with this example: > > http://www.haskell.org/haskellwiki/HXT#Getting_started:_Hello_world_example >s > > but it just died with out of memory. HXML just works. I have not tried the > Light XML library because it doesn't provide Arrow interface. What you can try with HXT is to use the readDocument arrow with the option to use the tagsoup parser for parsing. Then HXT really does lazy input. And there is a memory optimization for sharing the strings representing element and attribute names. But there is no DTD processing and no validating functionality with tagsoup. Most efficient input encoding is ISO Latin1 (or ASCII). Cheers Uwe -- Uwe Schmidt Web: http://www.fh-wedel.de/~si/ From sebastian.sylvan at gmail.com Fri Oct 24 09:19:31 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Fri Oct 24 09:15:04 2008 Subject: [Haskell] ANNOUNCE: colour 0.0.0 In-Reply-To: References: Message-ID: <3d96ac180810240619y4393ca89pc18b4a3a34381b4@mail.gmail.com> On Wed, Oct 22, 2008 at 1:12 AM, wrote: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/colour-0.0.0 > > I hope for this library to become the standard colour library for Haskell. > Most software does not properly blend colours because they fail to > gamma-correct the colours before blending. Hopefully by using this library, > Haskell programs dealing with colour blending will avoid this problem. > > I am making an early release of my colour library to get some feedback. I > am especially interested in getting feedback on the interfaces: should > functions be renamed, should functions be moved, etc. Should I put black and > white colours into Data.Colour? Which is better form making a colour: (sRGB > r g b) or (sRGB (r,g,b))? > > Bug reports and any patches are also welcome. Be warned, I haven't > extensively tested this library yet. > It would be nice if we could customize the gamma curve. Different devices have different gamma. Some hardware even approximates the gamma curve with piecewise linear functions. This can make a massive difference if you, e.g. degamma the image assuiming a gamma of 2.2 (typical office LCD screen), do some work on it, then convert to a gamma of 2.5 (typical TV - they assume TVs will be in a darker background setting), then the graphics card reads this as sRGB with its own piecewise linear approximation, then does some more work on it, and converts it back. Long story short, if you can't get all of those steps right the errors can add up quickly and becomes very noticable. If it could read photoshop colour profiles that would be even better. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20081024/e918e041/attachment-0001.htm From d at vidplace.com Fri Oct 24 11:10:51 2008 From: d at vidplace.com (David F. Place) Date: Fri Oct 24 11:06:25 2008 Subject: [Haskell] Re: Current XML libraries status In-Reply-To: <200810241244.12681.si@fh-wedel.de> References: <200810241244.12681.si@fh-wedel.de> Message-ID: <9D1322B0-D827-407B-A03D-F14DEC4C5BDA@vidplace.com> I tried to use HXT's readDocument with its tagsoup option for my application. I couldn't find a way to construct the operation that didn't run out of memory. I'll attach some code using HaXml's saxParse so you can see what I want. Is that easy to do in HXT? I simply want the text of and elements. -------------- next part -------------- A non-text attachment was scrubbed... Name: phase1.hs Type: application/octet-stream Size: 531 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell/attachments/20081024/5ebf4e72/phase1.obj -------------- next part -------------- Please feel free to bounce this to Haskell Cafe if you feel it is more appropriate. On Oct 24, 2008, at 12:44 PM, Uwe Schmidt wrote: > What you can try with HXT is to use the readDocument arrow > with the option to use the tagsoup parser for parsing. > Then HXT really does lazy input. _____________ David F. Place d@vidplace.com From roconnor at theorem.ca Fri Oct 24 15:12:07 2008 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Fri Oct 24 15:07:34 2008 Subject: [Haskell] ANNOUNCE: colour 0.0.0 In-Reply-To: <3d96ac180810240619y4393ca89pc18b4a3a34381b4@mail.gmail.com> References: <3d96ac180810240619y4393ca89pc18b4a3a34381b4@mail.gmail.com> Message-ID: On Fri, 24 Oct 2008, Sebastian Sylvan wrote: > It would be nice if we could customize the gamma curve. Different devices have different gamma. > Some hardware even approximates the gamma curve with piecewise linear functions. This can make a > massive difference if you, e.g. degamma the image assuiming a gamma of 2.2 (typical office LCD > screen), do some work on it, then convert to a gamma of 2.5 (typical TV - they assume TVs will be > in a darker background setting), then the graphics card reads this as sRGB with its own piecewise > linear approximation, then does some more work on it, and converts it back. Long story short, if > you can't get all of those steps right the errors can add up quickly and becomes very noticable. That is a fair point. I've only just started thinking about colour correction due to viewing environments. I remembered that dealing with colour was difficult (which is why I'm writing this library), but I forgot exactly how difficult it was. I just finished user defined linear RGB spaces in my development version. Allowing user defined non-linear RGB spaces would be a reasonable addition. > If it could read photoshop colour profiles that would be even better. Perhaps ICC profiles would do? Or are they the same thing? -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From sebastian.sylvan at gmail.com Fri Oct 24 17:51:13 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Fri Oct 24 17:46:41 2008 Subject: [Haskell] ANNOUNCE: colour 0.0.0 In-Reply-To: References: <3d96ac180810240619y4393ca89pc18b4a3a34381b4@mail.gmail.com> Message-ID: <3d96ac180810241451n41646d22wf383093d48cbb6a4@mail.gmail.com> On Fri, Oct 24, 2008 at 8:12 PM, wrote: > On Fri, 24 Oct 2008, Sebastian Sylvan wrote: > > It would be nice if we could customize the gamma curve. Different devices >> have different gamma. >> Some hardware even approximates the gamma curve with piecewise linear >> functions. This can make a >> massive difference if you, e.g. degamma the image assuiming a gamma of 2.2 >> (typical office LCD >> screen), do some work on it, then convert to a gamma of 2.5 (typical TV - >> they assume TVs will be >> in a darker background setting), then the graphics card reads this as sRGB >> with its own piecewise >> linear approximation, then does some more work on it, and converts it >> back. Long story short, if >> you can't get all of those steps right the errors can add up quickly and >> becomes very noticable. >> > > That is a fair point. I've only just started thinking about colour > correction due to viewing environments. I remembered that dealing with > colour was difficult (which is why I'm writing this library), but I forgot > exactly how difficult it was. > > I just finished user defined linear RGB spaces in my development version. > Allowing user defined non-linear RGB spaces would be a reasonable addition. Another useful predefined space which I didn't see is the YCoCg space, which is used in lots of compression schemes (like H.264 IIRC). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20081024/c5168699/attachment.htm From coeus at gmx.de Fri Oct 24 20:14:21 2008 From: coeus at gmx.de (Marc A. Ziegert) Date: Fri Oct 24 20:09:59 2008 Subject: [Haskell] Current XML libraries status In-Reply-To: References: Message-ID: <200810250214.31728.coeus@gmx.de> there was a thread about xml parsing, one month ago. well, i don't know much about xml, except what it looks like; but i know about that interesting parsing problem behind it. maybe Lev Walkin has fixed that in HXML. at least he wrote this patch... - marc ----- sometimes i think, i should write a paper about it. but then... naah, i'm like haskell: non-strict. Am Donnerstag, 23. Oktober 2008 schrieb Krasimir Angelov: > Hi, > > Does some one have made performance tests on the different XML libraries for > Haskell? I have a 20MB xml file that I want to read. I remember from my > earlier experiments (years ago) that all libraries were too slow and were > consuming too much memory. I hoped that this situation had changed but maybe > not. I looked at HaXML, libxml, HXML and HXT. HaXML eats a lot of memory and > is still very slow. libxml is unfinished binding to the C library. Currently > it only allows to create documents. HXML seems to be very promising. It > works fast and it doesn't eat memory. Unfortunately it is that it seems to > be rather old. It uses its own Arrow and Tree libraries instead of the > standard libraries. I have not jumped into HXT yet because it seems to be > very large library. Could someone recomend which one is the state of the > art? > > Best Regards, > Krasimir > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/haskell/attachments/20081025/97deeb37/attachment.bin From kr.angelov at gmail.com Sat Oct 25 04:09:37 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Sat Oct 25 04:05:52 2008 Subject: [Haskell] Current XML libraries status In-Reply-To: <200810250214.31728.coeus@gmx.de> References: <200810250214.31728.coeus@gmx.de> Message-ID: Hi Marc, Thanks for the pointer. Fortunately I don't have this problem. Probably 2GB of memory are enough to parse 20MB file even with this space leak. HXML still works better than the other libraries and has a nice API so I use it. The patch is useful but it is not applied. I also did some other changes in HXML. It seems like the library is not maintained. Should I package it and upload to Hackage? Regards, Krasimir On Sat, Oct 25, 2008 at 2:14 AM, Marc A. Ziegert wrote: > there was a thread about xml parsing, one month ago. > > well, i don't know much about xml, except what it looks like; > but i know about that interesting parsing problem behind it. > maybe Lev Walkin has fixed that in HXML. at least he wrote this patch... > > > - marc > > > ----- > sometimes i think, i should write a paper about it. but then... naah, i'm > like haskell: non-strict. > > > > > Am Donnerstag, 23. Oktober 2008 schrieb Krasimir Angelov: > > Hi, > > > > Does some one have made performance tests on the different XML libraries > for > > Haskell? I have a 20MB xml file that I want to read. I remember from my > > earlier experiments (years ago) that all libraries were too slow and were > > consuming too much memory. I hoped that this situation had changed but > maybe > > not. I looked at HaXML, libxml, HXML and HXT. HaXML eats a lot of memory > and > > is still very slow. libxml is unfinished binding to the C library. > Currently > > it only allows to create documents. HXML seems to be very promising. It > > works fast and it doesn't eat memory. Unfortunately it is that it seems > to > > be rather old. It uses its own Arrow and Tree libraries instead of the > > standard libraries. I have not jumped into HXT yet because it seems to be > > very large library. Could someone recomend which one is the state of the > > art? > > > > Best Regards, > > Krasimir > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20081025/19bdf954/attachment.htm From byorgey at seas.upenn.edu Sat Oct 25 18:28:22 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Oct 25 18:24:02 2008 Subject: [Haskell] Haskell Weekly News: Issue 90 - October 25, 2008 Message-ID: <20081025222821.GA8036@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20081025 Issue 90 - October 25, 2008 --------------------------------------------------------------------------- Welcome to issue 90 of HWN, a newsletter covering developments in the [1]Haskell community. One day a Haskell n00b asked the master coder, "Master, does (const 3 undefined) have the terminating nature, or not?" The master replied, "Of course." Cried the n00b, "But that changes everything! Why did you not tell me this before?" "You never asked." Immediately, the n00b was enlightened. Announcements Darcs hacking sprint. Eric Kow [2]announced that the [3]darcs hacking sprint is taking place this weekend! Lambdabot 4.2.2. Gwern Branwen [4]announced the release of [5]version 4.2.2 of lambdabot, the famous Haskell IRC bot. The new release has innumerable new features and bugfixes, trained suckling pigs, mermaids, etc. Autoproc Change of Maintainer (if you use procmail you should read this). Jason Dagit [6]announced that Gwern Branwen will be taking over the [7]autoproc project. Autoproc makes it quick and easy for Haskell programmers to make procmail recipes by using an embedded domain specific language. Once your recipes type check and compile, you simply run autoproc and it generates the corresponding procmail recipe. External Sort: Sort a 10-million integer file with just 256M of ram.. Thomas Hartman [8]announced the external-sort package. It implements an on-disk external sort algorithm in Haskell, which you can use to sort lists that will not fit in memory. IEEE-utils. Sterling Clover [9]announced the [10]IEEE-utils package, providing a number of bindings for anyone interested in doing hardcore floating-point programming. rewriting-0.1. Thomas van Noort [11]announced the release of [12]rewriting, a generic rewriting library for regular datatypes. Features include generic rewriting machinery, generic traversals, and rewrite rules defined as values instead of functions. REMINDER: Haskell Communities and Activities Report. Janis Voigtlaender [13]reminded everyone that the deadline for the November 2008 edition of the Haskell Communities and Activities Report (Friday, October 31) is approaching fast! If you haven't already, please write an entry for your new project, or update your old entry. For more information, see the original [14]call for contributions. lhs2tex-1.14. Andres Loeh [15]announced the release of [16]lhs2TeX version 1.14, a a preprocessor to generate LaTeX code from literate Haskell sources. colour 0.0.0. roconnor [17]announced an initial release of the [18]colour package. It is hoped that this library will become the standard colour library for Haskell. Discussion Hackage Improvement Ideas. Jason Dagit [19]suggested some improvements to Hackage and asked for others to contribute their ideas as well. Spine-lazy "multiqueue". Luke Palmer [20]asked for help implementing an efficient spine-lazy multiqueue. Jobs Functional programming job opening. Simon Peyton-Jones [21]announced a [22]job opening in functional programming at Microsoft. They are looking for "an experienced software development engineer who has mastered C/C++ and/or C# development and is now learning or is already an expert using F# (or Haskell)." Blog noise [23]Haskell news from the [24]blogosphere. * Eric Kow (kowey): [25]darcs hacking sprints - some pictures from Team Brighton. * Jason Dagit: [26]Understanding Darcs Commute. * Ketil Malde: [27]Optimization again: befuddled by bytestrings. * Creighton Hogg: [28]Revisiting old concepts. * Tupil: [29]On unit testing and type checking. * Eric Kow (kowey): [30]darcs weekly news #9. * >>> Alberto Corona: [31]Axioms and properties for haskell classes. Alberto demonstrates some code for adding checkable algebraic properties to type classes. * Creighton Hogg: [32]A serious problem. Creighton with some straight talk about typeclass abuse. * London Haskell Users Group: [33]Next meeting: Duncan Coutts on the Haskell Platform. * Manuel M T Chakravarty: [34]Keep those cores busy!. A comprehensive account of the full vectorisation transformation underlying the implementation of nested data parallelism in GHC. * Conal Elliott: [35]Simpler, more efficient, functional linear maps. * Conal Elliott: [36]Vector space bases via type families. * >>> Sebastian Fischer: [37]Constrained Monadic Computations. * Luke Palmer: [38]I know what I'm going to get for christmas. "I believe I have found a truly marvelous implementation of FRP which this blog post is too short to contain." * >>> codeflow: [39]On Haskell and C++. * >>> Simon Dobson: [40]Why Haskell will take over the world. Simon has some thoughts on functional programming and the future of programming languages. * >>> Falko: [41]Learning Haskell's Basics - Problems from Project Euler. Quotes of the Week * vixey: debugging code is admitting defeat * kaomoji: [on #haskell] man, you guys are really nerdy * sclv: I guess I'd believe the universe was lazy if the hubble looked at that stuff way at the edge of the big bang diaspora and when we magnified the picture we saw "stack overflow" * rwbarton: relational calculus? "DIFFERENTIATE TABLE users WITH RESPECT TO name" * heatsink: ban :: (BanContext no, UserIdentifer u) => u -> no u * rwbarton: I tried typechecking the value of unwords (replicate 125 "fmap") in ghci once, and it consumed all my memory * ghc: Step 3: Zonk the kinds About the Haskell Weekly News New editions are posted to [42]the Haskell mailing list as well as to [43]the Haskell Sequence and [44]Planet Haskell. [45]RSS is also available, and headlines appear on [46]haskell.org. To help create new editions of this newsletter, please see the information on [47]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [48]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://www.haskell.org//pipermail/haskell-cafe/2008-October/049775.html 3. http://wiki.darcs.net/index.html/Sprints 4. http://article.gmane.org/gmane.comp.lang.haskell.cafe/46842 5. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/lambdabot 6. http://article.gmane.org/gmane.comp.lang.haskell.cafe/46841 7. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/autoproc 8. http://article.gmane.org/gmane.comp.lang.haskell.cafe/46776 9. http://www.haskell.org//pipermail/haskell-cafe/2008-October/049760.html 10. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ieee-utils 11. http://article.gmane.org/gmane.comp.lang.haskell.cafe/46750 12. http://www.cs.uu.nl/wiki/GenericProgramming/Rewriting 13. http://article.gmane.org/gmane.comp.lang.haskell.cafe/46696 14. http://www.haskell.org/pipermail/haskell/2008-October/020651.html 15. http://article.gmane.org/gmane.comp.lang.haskell.general/16538 16. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/lhs2tex 17. http://article.gmane.org/gmane.comp.lang.haskell.general/16524 18. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/colour 19. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/46764 20. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/46710 21. http://article.gmane.org/gmane.comp.lang.haskell.general/16511 22. http://members.microsoft.com/careers/search/details.aspx?JobID=E29D3886-A152-4D95-873D-8890EFB683AD&start=1&interval=10&SortCol=DatePosted 23. http://planet.haskell.org/ 24. http://haskell.org/haskellwiki/Blog_articles 25. http://koweycode.blogspot.com/2008/10/darcs-hacking-sprints-some-pictures.html 26. http://blog.codersbase.com/2008/10/24/understanding-darcs-commute/ 27. http://blog.malde.org/index.php/2008/10/24/optimization-again-befuddled-by-bytestrings/ 28. http://abstractabsurd.blogspot.com/2008/10/revisiting-old-concepts.html 29. http://blog.tupil.com/on-unit-testing-and-type-checking/ 30. http://koweycode.blogspot.com/2008/10/darcs-weekly-news-9.html 31. http://haskell-web.blogspot.com/2008/10/axioms-properties-for-haskell-classes.html 32. http://abstractabsurd.blogspot.com/2008/10/serious-problem.html 33. http://www.londonhug.net/2008/10/22/next-meeting-duncan-coutts-on-the-haskell-platform/ 34. http://justtesting.org/post/55387637 35. http://feeds.feedburner.com/~r/conal/~3/425946113/ 36. http://feeds.feedburner.com/~r/conal/~3/425935010/ 37. http://www-ps.informatik.uni-kiel.de/~sebf/projects/constraint-monad.html 38. http://luqui.org/blog/archives/2008/10/19/i-know-what-im-going-to-get-for-christmas/ 39. http://codeflow.wordpress.com/2008/10/18/on-haskell-and-c/ 40. http://www.simondobson.org/?p=179 41. http://informatikr.wordpress.com/2008/10/13/learning-haskells-basics-problems-from-project-euler/ 42. http://www.haskell.org/mailman/listinfo/haskell 43. http://sequence.complete.org/ 44. http://planet.haskell.org/ 45. http://sequence.complete.org/node/feed 46. http://haskell.org/ 47. http://haskell.org/haskellwiki/HWN 48. http://code.haskell.org/~byorgey/code/hwn/ From ehaussecker at gmail.com Sun Oct 26 05:27:10 2008 From: ehaussecker at gmail.com (Enzo Haussecker) Date: Sun Oct 26 05:22:35 2008 Subject: [Haskell] Publication of InputYourData.com + Project Announceme Message-ID: I would like to announce the publication of InputYourData.com (beta) ? the online resource tool for financial, mathematical and scientific calculations. All web applications found at http://inputyourdata.com/ are written solely in Haskell and based on the Network.CGI framework. This website began as an experiment to familiarize myself with the monadic features of Haskell and their use in web programming. Namely, the mapping and manipulation of user inputs as typed objects. Through these experiments I found that Haskell allows for an efficient system where a variety of operations can be preformed while minimizing as many resources (such as time and memory space) as possible. I am now interested in developing a similar type of website, except wiki style ? where all web applications are created by the user. Essentially, I am designing a web application where users can symbolically declare the arguments of a function and that function's call based on arbitrary variables. For example, say a user would like to create a web application to compute the roots of a second degree polynomial. He/she would simply declare the arguments to her function ? three complex numbers a b and c, and the call of that function ? (-b ? sqrt (b^2 - 4*a*c))/(2*a). The product of that users inputs will render a web application that looks similar to http:// inputyourdata.com/cgi-bin/quadratic.cgi (all text is to be updated by the user as well). As one could imagine, other, more complex functions involving vectors, matrices, stock prices, and other arguments can also be defined in terms of arbitrary variables and declared as an inputs to my wiki-style web application. If you are intrigued by this project and you have substantial experience in designing Haskell-based web applications, please send me your resume and a brief summery of why you are interested. Regards, Enzo Haussecker ehaussecker@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20081026/4d358a2b/attachment.htm From ehaussecker at gmail.com Sun Oct 26 05:29:16 2008 From: ehaussecker at gmail.com (Enzo Haussecker) Date: Sun Oct 26 05:24:38 2008 Subject: [Haskell] Publication of InputYourData.com + Project Announcement Message-ID: I would like to announce the publication of InputYourData.com (beta) ? the online resource tool for financial, mathematical and scientific calculations. All web applications found at http://inputyourdata.com/ are written solely in Haskell and based on the Network.CGI framework. This website began as an experiment to familiarize myself with the monadic features of Haskell and their use in web programming. Namely, the mapping and manipulation of user inputs as typed objects. Through these experiments I found that Haskell allows for an efficient system where a variety of operations can be preformed while minimizing as many resources (such as time and memory space) as possible. I am now interested in developing a similar type of website, except wiki style ? where all web applications are created by the user. Essentially, I am designing a web application where users can symbolically declare the arguments of a function and that function's call based on arbitrary variables. For example, say a user would like to create a web application to compute the roots of a second degree polynomial. He/she would simply declare the arguments to her function ? three complex numbers a b and c, and the call of that function ? (-b ? sqrt (b^2 - 4*a*c))/(2*a). The product of that users inputs will render a web application that looks similar to http:// inputyourdata.com/cgi-bin/quadratic.cgi (all text is to be updated by the user as well). As one could imagine, other, more complex functions involving vectors, matrices, stock prices, and other arguments can also be defined in terms of arbitrary variables and declared as an inputs to my wiki-style web application. If you are intrigued by this project and you have substantial experience in designing Haskell-based web applications, please send me your resume and a brief summery of why you are interested. Regards, Enzo Haussecker ehaussecker@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20081026/d33f4f59/attachment.htm From ehaussecker at gmail.com Sun Oct 26 05:31:34 2008 From: ehaussecker at gmail.com (Enzo Haussecker) Date: Sun Oct 26 05:26:56 2008 Subject: [Haskell] Publication of InputYourData.com + Project Announcement Message-ID: I would like to announce the publication of InputYourData.com (beta) ? the online resource tool for financial, mathematical and scientific calculations. All web applications found at http://inputyourdata.com/ are written solely in Haskell and based on the Network.CGI framework. This website began as an experiment to familiarize myself with the monadic features of Haskell and their use in web programming. Namely, the mapping and manipulation of user inputs as typed objects. Through these experiments I found that Haskell allows for an efficient system where a variety of operations can be preformed while minimizing as many resources (such as time and memory space) as possible. I am now interested in developing a similar type of website, except wiki style ? where all web applications are created by the user. Essentially, I am designing a web application where users can symbolically declare the arguments of a function and that function's call based on arbitrary variables. For example, say a user would like to create a web application to compute the roots of a second degree polynomial. He/she would simply declare the arguments to her function ? three complex numbers a b and c, and the call of that function ? (-b ? sqrt (b^2 - 4*a*c))/(2*a). The product of that users inputs will render a web application that looks similar to http://inputyourdata.com/cgi-bin/quadratic.cgi (all text is to be updated by the user as well). As one could imagine, other, more complex functions involving vectors, matrices, stock prices, and other arguments can also be defined in terms of arbitrary variables and declared as an inputs to my wiki-style web application. If you are intrigued by this project and you have substantial experience in designing Haskell-based web applications, please send me your resume and a brief summery of why you are interested. Regards, Enzo Haussecker ehaussecker@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20081026/43e22b3c/attachment.htm From ehaussecker at gmail.com Sun Oct 26 05:33:02 2008 From: ehaussecker at gmail.com (Enzo Haussecker) Date: Sun Oct 26 05:28:24 2008 Subject: [Haskell] Publication of InputYourData.com + Project Announcement In-Reply-To: References: Message-ID: I would like to announce the publication of InputYourData.com (beta) ? the online resource tool for financial, mathematical and scientific calculations. All web applications found at http://inputyourdata.com/ are written solely in Haskell and based on the Network.CGI framework. This website began as an experiment to familiarize myself with the monadic features of Haskell and their use in web programming. Namely, the mapping and manipulation of user inputs as typed objects. Through these experiments I found that Haskell allows for an efficient system where a variety of operations can be preformed while minimizing as many resources (such as time and memory space) as possible. I am now interested in developing a similar type of website, except wiki style ? where all web applications are created by the user. Essentially, I am designing a web application where users can symbolically declare the arguments of a function and that function's call based on arbitrary variables. For example, say a user would like to create a web application to compute the roots of a second degree polynomial. He/she would simply declare the arguments to her function ? three complex numbers a b and c, and the call of that function ? (-b ? sqrt (b^2 - 4*a*c))/(2*a). The product of that users inputs will render a web application that looks similar to http://inputyourdata.com/cgi-bin/quadratic.cgi (all text is to be updated by the user as well). As one could imagine, other, more complex functions involving vectors, matrices, stock prices, and other arguments can also be defined in terms of arbitrary variables and declared as an inputs to my wiki-style web application. If you are intrigued by this project and you have substantial experience in designing Haskell-based web applications, please send me your resume and a brief summery of why you are interested. Regards, Enzo Haussecker ehaussecker@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20081026/4e0c218c/attachment.htm From marte at pms.informatik.uni-muenchen.de Mon Oct 27 15:48:28 2008 From: marte at pms.informatik.uni-muenchen.de (Michael Marte) Date: Mon Oct 27 15:43:55 2008 Subject: [Haskell] Re: No fun with phantom types In-Reply-To: References: <200810232156.19080.marte@pms.informatik.uni-muenchen.de> Message-ID: <200810272048.29244.marte@pms.informatik.uni-muenchen.de> Hello David, thank you, the functional dependency solved the problem! Nevertheless, I think it is worth considering the phantom type variable a second time. It makes easy things quite hard and requires a lot of not-(yet?)-standard features of the type system. As there is usually no second problem instance a variable could escape to, the price for the theoretical safety is probably too high. I studied your solver for arithmetic constraints and, after some thinking, I prefer your approach over mine because it is more natural (no posting function required that implements the compiler) though it does not allow for automatic analysis and transformations. For example, with the ADT approach a system of linear equalities and inequalities could be recognized as a linear program and replaced by a specialized global lp constraint. However, as the lp constraint can be applied directly as well, omitting the transformation stage does not hurt. Concering bad performance, there are several things that come to my mind: * Domain access in not O(1). varMap should be replaced by an array. * Pruning IntSet domains is inefficient: filterLessThan and filterGreaterThan are O(n) due to the use of IntSet.filter which should be replaced by IntSet.split. * No search strategy: One should always try to label one of the "most constrained" variables. A proven way to do this is to label one of the variables with the smallest domain. * Splitting domains instead of labelling: Depending on the problem, on the way it is modelled, and on the operational properties of the constraints employed in the model, it may be better to split domains, i.e. choose a non-ground variable x and generate two subproblems, one with x .=<. a and one with x .>. a where a is some element between the lower and upper bound of x, usually the middle. * Correctness: The implementation of .*. is faulty; its pruning is too strong: *FD> clp (do x <- newNamedVar (0, 9) "x"; 10 .*. x .==. 90) _1: (10,10) _2: (90,90) _3: (90,90) x: (9,9) ? ; no *FD> clp (do x <- newNamedVar (0, 9) "x"; 10 .*. x .==. 80) no (The clp and newNamedVar functions are described on http://mmartedp.blogspot.com/ and contained in the patch I attached to this mail.) That's why sendMoreMoney has no solutions and, of course, bugs like this one may render easy problems difficult by pruning solutions resulting in long runtimes. Michael On Friday 24 October 2008 01:17:07 am you wrote: > Hi Michael, > > You need a functional depenency in the class to make this work. Something > like > > class MakeAExp a s | a -> s where > makeAExp :: a -> AExp s > > should work, although I haven't tested it with your code. > > I did actually extend my FD constraint solver with arithmetic > constraints myself, but I never got time to post it on my blog. It's > also very inefficient at the moment, at least compared to the clp(fd) > solver in GnuProlog. > > I took a slightly different approach to you. Instead of using an > algebraic data type for expressions, I represent each node in the > expression as a new FDVar in the constraint store. > I've attached a copy of my code if you're interested. Let me know how > you get on. > > David -------------- next part -------------- A non-text attachment was scrubbed... Name: clpStuffPatch.zip Type: application/x-zip Size: 1461 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell/attachments/20081027/5c008a11/clpStuffPatch-0001.bin From rodprice at raytheon.com Mon Oct 27 18:27:26 2008 From: rodprice at raytheon.com (Rodney D Price) Date: Mon Oct 27 18:22:53 2008 Subject: [Haskell] IORef sharing Message-ID: I'm trying to understand how an IORef (MVar, TVar) might be shared between separate instances of function closures. I've defined a function `count` that returns a function with an IORef "inside", > count :: IORef Int -> Int -> IO (Char -> IO Int) > count io i = do > writeIORef io i > return (\c -> if c == 'a' > then modifyIORef io (+1) >> readIORef io > else readIORef io) Now I define an IORef and a couple of counters that share the IORef, > iio :: IO (IORef Int) > iio = newIORef 0 > ic1 = do { io <- iio ; count io 0 } > ic2 = do { io <- iio ; count io 0 } I expected to see the counters sharing the IORef, so that executing `counter1` below would print "1,1,2,3". Instead, it prints "1,0,1,2". > counter1 = do > c1 <- ic1 > c2 <- ic2 > c1 'a' >>= print > c2 'b' >>= print > c2 'a' >>= print > c1 'a' >>= print However, if I create the two counters inside the same do block, I get the result I expected, "1,1,2,3". > counter2 = do > io <- iio > c1 <- count io 0 > c2 <- count io 0 > c1 'a' >>= print > c2 'b' >>= print > c2 'a' >>= print > c1 'a' >>= print So apparently my mental picture of an IORef as a pointer to a value is wrong. I need a new mental picture. What's going on here? Thanks, -Rod From martijn at van.steenbergen.nl Mon Oct 27 18:36:37 2008 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Mon Oct 27 18:31:56 2008 Subject: [Haskell] IORef sharing In-Reply-To: References: Message-ID: <49064275.7040307@van.steenbergen.nl> Rodney D Price wrote: > I'm trying to understand how an IORef (MVar, TVar) might be > shared between separate instances of function closures. > I've defined a function `count` that returns a function with > an IORef "inside", > >> count :: IORef Int -> Int -> IO (Char -> IO Int) >> count io i = do >> writeIORef io i >> return (\c -> if c == 'a' >> then modifyIORef io (+1) >> readIORef io >> else readIORef io) > > Now I define an IORef and a couple of counters that share > the IORef, > >> iio :: IO (IORef Int) >> iio = newIORef 0 >> ic1 = do { io <- iio ; count io 0 } >> ic2 = do { io <- iio ; count io 0 } > > I expected to see the counters sharing the IORef, so that > executing `counter1` below would print "1,1,2,3". Instead, > it prints "1,0,1,2". > >> counter1 = do >> c1 <- ic1 >> c2 <- ic2 >> c1 'a' >>= print >> c2 'b' >>= print >> c2 'a' >>= print >> c1 'a' >>= print > > However, if I create the two counters inside the same do > block, I get the result I expected, "1,1,2,3". > >> counter2 = do >> io <- iio >> c1 <- count io 0 >> c2 <- count io 0 >> c1 'a' >>= print >> c2 'b' >>= print >> c2 'a' >>= print >> c1 'a' >>= print > > So apparently my mental picture of an IORef as a pointer > to a value is wrong. I need a new mental picture. What's > going on here? Naming the creation of a new IORef "iio" is not gonna make it return the same IORef every time you call iio. Imagine iio being expanded to its definition in your counter1 example (which is exactly what happens); would you still expect the result to be 1,1,2,3? If you want the IORef to be shared by different pieces of code, pass it around as an argument. Kind regards, Martijn. From rodprice at RAYTHEON.COM Mon Oct 27 19:02:54 2008 From: rodprice at RAYTHEON.COM (Rodney D Price) Date: Mon Oct 27 18:58:23 2008 Subject: [Haskell] IORef sharing In-Reply-To: <49064275.7040307@van.steenbergen.nl> References: <49064275.7040307@van.steenbergen.nl> Message-ID: My old, deeply flawed mental picture had "iio" taking the role of a pointer to a value. My bright, shiny new mental picture has "iio" acting just like a C #define macro: every time I call "iio", I'm really just writing "newIORef 0". Is that what you're saying? -Rod On Oct 27, 2008, at 4:36 PM, Martijn van Steenbergen wrote: > Rodney D Price wrote: >> >> So apparently my mental picture of an IORef as a pointer >> to a value is wrong. I need a new mental picture. What's >> going on here? > > Naming the creation of a new IORef "iio" is not gonna make it return > the same IORef every time you call iio. Imagine iio being expanded > to its definition in your counter1 example (which is exactly what > happens); would you still expect the result to be 1,1,2,3? If you > want the IORef to be shared by different pieces of code, pass it > around as an argument. > > Kind regards, > > Martijn. From allbery at ece.cmu.edu Mon Oct 27 19:16:08 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Oct 27 19:11:27 2008 Subject: [Haskell] IORef sharing In-Reply-To: References: <49064275.7040307@van.steenbergen.nl> Message-ID: <33C07ADF-E767-4FC7-8554-417255D2A49E@ece.cmu.edu> On 2008 Oct 27, at 19:02, Rodney D Price wrote: > My old, deeply flawed mental picture had "iio" taking > the role of a pointer to a value. My bright, shiny > new mental picture has "iio" acting just like a C > #define macro: every time I call "iio", I'm really > just writing "newIORef 0". Is that what you're saying? Sort of. What's really happening is that "newIORef" is an I/O action, just like "putStrLn", so will be executed every time it's used just as "putStrLn" is. If you want to do it only once, you must do it only once and pass the resulting IORef around. (There is also a way to do "global variables", but it's rather unsafe and requires telling the compiler to not rewrite the initialization code.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From jonathanccast at fastmail.fm Mon Oct 27 19:07:49 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Oct 27 19:11:56 2008 Subject: [Haskell] IORef sharing In-Reply-To: References: <49064275.7040307@van.steenbergen.nl> Message-ID: <1225148869.20284.37.camel@jcchost> On Mon, 2008-10-27 at 17:02 -0600, Rodney D Price wrote: > My old, deeply flawed mental picture had "iio" taking > the role of a pointer to a value. Not so much flawed: you just need to realize that Haskell considers the sub-program `create a new IORef with contents 0 and return it' to be a perfectly good value, and when you say iio = newIORef 0 Haskell is perfectly happy to point iio at that sub-program. Your problem is distinguishing `program' from `value' and thinking that `value' means `result of program'. Haskell knows no such distinction. > My bright, shiny > new mental picture has "iio" acting just like a C > #define macro: But this is a good intuition, too. Except without the weird syntax bugs. Also statically typed. And you can use recursion, etc. Other than that, `Haskell function = macro' isn't a bad (component of a) mental picture. > every time I call "iio", I'm really > just writing "newIORef 0". Write. So you say name = expression in Haskell when `name' is clearer in the contexts where it's used than `expression' is (or when expression needs to be recursive). jcc From martijn at van.steenbergen.nl Mon Oct 27 19:16:52 2008 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Mon Oct 27 19:12:11 2008 Subject: [Haskell] IORef sharing In-Reply-To: References: <49064275.7040307@van.steenbergen.nl> Message-ID: <49064BE4.1000100@van.steenbergen.nl> Rodney D Price wrote: > every time I call "iio", I'm really > just writing "newIORef 0". Is that what you're saying? Yes. :-) M. From tim at goddard.net.nz Mon Oct 27 19:43:14 2008 From: tim at goddard.net.nz (Timothy Goddard) Date: Mon Oct 27 19:38:34 2008 Subject: [Haskell] IORef sharing In-Reply-To: References: <49064275.7040307@van.steenbergen.nl> Message-ID: <200810281243.14712.tim@goddard.net.nz> On Tue, 28 Oct 2008 12:02:54 Rodney D Price wrote: > My old, deeply flawed mental picture had "iio" taking > the role of a pointer to a value. My bright, shiny > new mental picture has "iio" acting just like a C > #define macro: every time I call "iio", I'm really > just writing "newIORef 0". Is that what you're saying? > > -Rod No, this isn't the behaviour of IORefs at all - you're getting mixed up with Haskell's syntax. <- in a do block means perform the contained action and let me use the result. = defines a term and is effectively just an alias - it doesn't run anything by itself. > iio :: IO (IORef Int) This means "iio is an IO operation which produces an IORef to an Int" > iio = newIORef 0 This means "iio is creating a new counter starting at 0" > ic1 = do { io <- iio ; count io 0 } This is an IO operation which runs iio, creating a new IORef in the process, and then starts a counter at 0 and returns it. > ic2 = do { io <- iio ; count io 0 } This runs iio again, creating another IORef, and then starts a counter on the new IORef. Haskell doesn't have mutable global variables - it goes against the grain of a pure language. You have to create the IORef within an IO procedure and pass it in. You really should write: counter = do io <- newIORef 0 ? c1 <- count io 0 ? c2 <- count io 0 ? c1 'a' >>= print ? c2 'b' >>= print ? c2 'a' >>= print ? c1 'a' >>= print This should behave as you expected - it creates the IORef then creates two counters sharing it. Remember that when you return IO a, you're returning an IO operation that produces an a. That operation is not run until it is bound to the main IO monad. Haskell's IO looks like any other language if you're only writing and calling procedures normally but as soon as you start passing around references to IO procedures you need to understand a little more about how monads work. In the real world using IO counters is probably something to avoid. Only the part of your program that is actually interacting with the outside world should use IO at all, and keeping an internal count doesn't need this. Minimise IO and Haskell will reward you. Let IO spread all through your program and it will be no safer than the C the developer was really thinking in. Cheers, Tim From rodprice at raytheon.com Mon Oct 27 20:25:28 2008 From: rodprice at raytheon.com (Rodney D Price) Date: Mon Oct 27 20:21:51 2008 Subject: [Haskell] IORef sharing In-Reply-To: <200810281243.14712.tim@goddard.net.nz> References: <49064275.7040307@van.steenbergen.nl> <200810281243.14712.tim@goddard.net.nz> Message-ID: <563EDF5E-22BB-441B-BE32-DF61C72CF947@raytheon.com> Thanks for all the replies. Perhaps my mental picture is a little less flawed, now, but this brings up something about the IO monad that has always bothered me. Papers on the IO monad say things like "A term of type IO () denotes an action, but does not necessarily perform the action." (Wadler, "How to Declare an Imperative") Or, "putc '!' denotes the command that, if it is ever performed, will print an exclamation mark." Okay... However, when I use IO in a Haskell program, the response is usually pretty snappy. It's not as if the Haskell runtime is hanging around, waiting for some time in the future when it might be appropriate to do IO. It happens right now. Yet the literature gives the impression that the IO monad in particular is a clever trick to preserve referential transparency by gathering up all the IO actions, but not necessarily actually *performing* them. Then the Haskell runtime holds its nose and *performs* them when necessary. But at least a couple responses to my question have said that the IO action is performed when `<-` (or equivalently, bind, >>=) is executed. My head has a hard time holding a mental model of code in which IO might happen at some unspecified time in the future. A mental model in which IO happens when >>= is executed is a lot better fit for my head. Yet, I remain a bit nervous about this new (to me) mental model. Is this just an intuition that works 99.9% of the time, or is it actual, literal fact? -Rod On Oct 27, 2008, at 5:43 PM, Timothy Goddard wrote: > On Tue, 28 Oct 2008 12:02:54 Rodney D Price wrote: >> My old, deeply flawed mental picture had "iio" taking >> the role of a pointer to a value. My bright, shiny >> new mental picture has "iio" acting just like a C >> #define macro: every time I call "iio", I'm really >> just writing "newIORef 0". Is that what you're saying? >> >> -Rod > > No, this isn't the behaviour of IORefs at all - you're getting mixed > up with > Haskell's syntax. <- in a do block means perform the contained > action and let > me use the result. = defines a term and is effectively just an alias > - it > doesn't run anything by itself. > >> iio :: IO (IORef Int) > This means "iio is an IO operation which produces an IORef to an Int" >> iio = newIORef 0 > This means "iio is creating a new counter starting at 0" >> ic1 = do { io <- iio ; count io 0 } > This is an IO operation which runs iio, creating a new IORef in the > process, > and then starts a counter at 0 and returns it. >> ic2 = do { io <- iio ; count io 0 } > This runs iio again, creating another IORef, and then starts a > counter on the > new IORef. > > Haskell doesn't have mutable global variables - it goes against the > grain of a > pure language. You have to create the IORef within an IO procedure > and pass > it in. You really should write: > > counter = do > io <- newIORef 0 > c1 <- count io 0 > c2 <- count io 0 > c1 'a' >>= print > c2 'b' >>= print > c2 'a' >>= print > c1 'a' >>= print > > This should behave as you expected - it creates the IORef then > creates two > counters sharing it. > > Remember that when you return IO a, you're returning an IO operation > that > produces an a. That operation is not run until it is bound to the > main IO > monad. Haskell's IO looks like any other language if you're only > writing and > calling procedures normally but as soon as you start passing around > references to IO procedures you need to understand a little more > about how > monads work. > > In the real world using IO counters is probably something to avoid. > Only the > part of your program that is actually interacting with the outside > world > should use IO at all, and keeping an internal count doesn't need this. > Minimise IO and Haskell will reward you. Let IO spread all through > your > program and it will be no safer than the C the developer was really > thinking > in. > > Cheers, > > Tim > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From allbery at ece.cmu.edu Mon Oct 27 20:37:38 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Oct 27 20:33:02 2008 Subject: [Haskell] IORef sharing In-Reply-To: <563EDF5E-22BB-441B-BE32-DF61C72CF947@raytheon.com> References: <49064275.7040307@van.steenbergen.nl> <200810281243.14712.tim@goddard.net.nz> <563EDF5E-22BB-441B-BE32-DF61C72CF947@raytheon.com> Message-ID: <66EAD554-8DD3-48D5-BA0B-1AA9DD48DE0D@ece.cmu.edu> On 2008 Oct 27, at 20:25, Rodney D Price wrote: > Okay... However, when I use IO in a Haskell program, > the response is usually pretty snappy. It's not as > if the Haskell runtime is hanging around, waiting for > some time in the future when it might be appropriate > to do IO. It happens right now. Yet the literature > gives the impression that the IO monad in particular > is a clever trick to preserve referential transparency > by gathering up all the IO actions, but not necessarily > actually *performing* them. Then the Haskell runtime > holds its nose and *performs* them when necessary.0 The *conceptual* model for the IO monad is that "main" returns a big IO action which is then evaluated by the Haskell runtime. As a practical matter, this usually behaves the same as if <- actually did evaluation. (It doesn't. It binds monadic expressions together, and is a convenient way to use the (>>=) operator.) The one difference is its interaction with Haskell equations (a = b); since those are more or less macro definitions, assigning e.g. an expression of type IO String to such a "macro" will cause the expression to be substituted wherever the "macro" is used. IO is a very atypical monad, by the way. Someone pointed you earlier to the "IO Inside" page, which describes the internal tricks that make IO work. I prefer to think of IO actions as partially applied functions, with the missing argument being a "RealWorld" that is hidden inside the IO monad. (think: IO a = State RealWorld a. This isn't quite correct because the state also has IORefs inside it.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From eford at griptonite.com Mon Oct 27 21:35:53 2008 From: eford at griptonite.com (Eli Ford) Date: Mon Oct 27 21:31:13 2008 Subject: [Haskell] IORef sharing In-Reply-To: <563EDF5E-22BB-441B-BE32-DF61C72CF947@raytheon.com> Message-ID: <31ECB6BD3B41974AB11BACB17C05296E059119B1@kirkmail01.f9.internal> > Rodney D Price wrote: > > Okay... However, when I use IO in a Haskell program, > the response is usually pretty snappy. It's not as > if the Haskell runtime is hanging around, waiting for > some time in the future when it might be appropriate > to do IO. It happens right now. Yet the literature > gives the impression that the IO monad in particular > is a clever trick to preserve referential transparency > by gathering up all the IO actions, but not necessarily > actually *performing* them. Then the Haskell runtime > holds its nose and *performs* them when necessary. It's really best to think of 'main' as returning an IO action. You can call >>= all over the place, but if you never return the result up through 'main', the resulting bound action will never be executed. (Even then it might not be executed, if the runtime never passes through that point in your program.) Coming from an imperative background, I imagine that 'main' returns pretty much immediately, and the runtime starts executing your action right away. To put it another way, 'main' is a constant -- it doesn't do work, so much as it describes what you want the runtime to do. Hope this helps! From monnier at iro.umontreal.ca Mon Oct 27 21:44:56 2008 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Mon Oct 27 21:40:28 2008 Subject: [Haskell] Re: IORef sharing References: Message-ID: >> iio :: IO (IORef Int) >> iio = newIORef 0 I sometimes feel like "IO" should be renamed to "CommandSequenceReturning". So the above would read: iio :: CommandSequenceReturning (IORef Int) iio = newIORef 0 I.e. iio is not an IORef Int but only a (trivial) sequence of commands that will end up returning an object of (IORef Int) when it'll be executed. Stefan From jake at pikewerks.com Mon Oct 27 23:34:02 2008 From: jake at pikewerks.com (Jake Mcarthur) Date: Mon Oct 27 23:29:21 2008 Subject: [Haskell] IORef sharing In-Reply-To: <563EDF5E-22BB-441B-BE32-DF61C72CF947@raytheon.com> References: <49064275.7040307@van.steenbergen.nl> <200810281243.14712.tim@goddard.net.nz> <563EDF5E-22BB-441B-BE32-DF61C72CF947@raytheon.com> Message-ID: <9CF698CF-BC13-442B-8285-C7AEF0C9B375@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 27, 2008, at 7:25 PM, Rodney D Price wrote: > Perhaps my mental picture is a little less flawed, > now, but this brings up something about the IO > monad that has always bothered me. Papers on the > IO monad say things like "A term of type IO () > denotes an action, but does not necessarily perform > the action." (Wadler, "How to Declare an Imperative") > Or, "putc '!' denotes the command that, if it is ever > performed, will print an exclamation mark." I like to think of the IO monad as a lazy imperative program generator. That is, the runtime lazily evaluates actions as they are needed, perhaps as though main is a (potentially infinite) lazy list of actions. In my mental model, runtime basically works like: What should I do first? *evaluate first action* *perform action* What should I do next? *evaluate next action* *perform action* What should I do next? *evaluate next action* *perform action* What should I do next? *evaluate next action* *perform action* ... - - Jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkGiCoACgkQye5hVyvIUKkBhACgsT4zg5D+FBkLx7+qBu4xcWvF gYwAnR+wrDdipCHAhJP2cTNcoq54ZklU =OM1+ -----END PGP SIGNATURE----- From simonpj at microsoft.com Tue Oct 28 05:03:58 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Oct 28 04:58:13 2008 Subject: [Haskell] IORef sharing In-Reply-To: <66EAD554-8DD3-48D5-BA0B-1AA9DD48DE0D@ece.cmu.edu> References: <49064275.7040307@van.steenbergen.nl> <200810281243.14712.tim@goddard.net.nz> <563EDF5E-22BB-441B-BE32-DF61C72CF947@raytheon.com> <66EAD554-8DD3-48D5-BA0B-1AA9DD48DE0D@ece.cmu.edu> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D7A356DDE@EA-EXMSG-C334.europe.corp.microsoft.com> This would be an excellent thread for the Haskell Cafe mailing list, haskell-cafe@haskell.org However, it's becoming over-long for the main list http://haskell.org/haskellwiki/Mailing_lists#Mailing_lists_in_detail Thanks! Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On | Behalf Of Brandon S. Allbery KF8NH | Sent: 28 October 2008 00:38 | To: Rodney D Price | Cc: haskell@haskell.org | Subject: Re: [Haskell] IORef sharing | | On 2008 Oct 27, at 20:25, Rodney D Price wrote: | > Okay... However, when I use IO in a Haskell program, | > the response is usually pretty snappy. It's not as | > if the Haskell runtime is hanging around, waiting for | > some time in the future when it might be appropriate | > to do IO. It happens right now. Yet the literature | > gives the impression that the IO monad in particular | > is a clever trick to preserve referential transparency | > by gathering up all the IO actions, but not necessarily | > actually *performing* them. Then the Haskell runtime | > holds its nose and *performs* them when necessary.0 | | The *conceptual* model for the IO monad is that "main" returns a big | IO action which is then evaluated by the Haskell runtime. | | As a practical matter, this usually behaves the same as if <- actually | did evaluation. (It doesn't. It binds monadic expressions together, | and is a convenient way to use the (>>=) operator.) The one | difference is its interaction with Haskell equations (a = b); since | those are more or less macro definitions, assigning e.g. an expression | of type IO String to such a "macro" will cause the expression to be | substituted wherever the "macro" is used. | | IO is a very atypical monad, by the way. Someone pointed you earlier | to the "IO Inside" page, which describes the internal tricks that make | IO work. I prefer to think of IO actions as partially applied | functions, with the missing argument being a "RealWorld" that is | hidden inside the IO monad. (think: IO a = State RealWorld a. This | isn't quite correct because the state also has IORefs inside it.) | | -- | brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com | system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu | electrical and computer engineering, carnegie mellon university KF8NH | | | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From haihualin at 163.com Tue Oct 28 10:38:50 2008 From: haihualin at 163.com (haihualin) Date: Tue Oct 28 10:34:09 2008 Subject: [Haskell] How to get the binary respentation of the Int/Double. Message-ID: <200810282238493915117@163.com> Hi, I am wondering how to get the binary respentation of the Int/Double. So I can save the integer as the binary data so that the C program can read it from the file. Thanks for your help. Haihua From nlv at lab321.ru Tue Oct 28 11:18:51 2008 From: nlv at lab321.ru (nlv) Date: Tue Oct 28 11:19:32 2008 Subject: [Haskell] Problem with installing wxHaskell Message-ID: <49072D5B.8000300@lab321.ru> Hello. I cannot install wxHaskell. I've installed wxX11-2.8.8 and tried to install wxcore-0.10.5. But on "make" I've got: wxc/include/wrapper.h:151: error: invalid use of undefined type ?struct wxDropTarget? /usr/local/include/wx-2.8/wx/window.h:60: error: forward declaration of ?struct wxDropTarget? wxc/include/wrapper.h:170: error: ?wxDragResult? does not name a type wxc/include/wrapper.h:172: error: ?wxDragResult? does not name a type wxc/include/wrapper.h:173: error: ?wxDragResult? does not name a type wxc/include/wrapper.h: In constructor ?ELJDropTarget::ELJDropTarget(void*)?: wxc/include/wrapper.h:161: error: type ?wxDropTarget? is not a direct base of ?ELJDropTarget? wxc/include/wrapper.h: At global scope: wxc/include/wrapper.h:199: error: expected class-name before ?{? token wxc/include/wrapper.h:222: error: ?wxDragResult? does not name a type wxc/include/wrapper.h:224: error: ?wxDragResult? does not name a type wxc/include/wrapper.h:225: error: ?wxDragResult? does not name a type wxc/include/wrapper.h: In constructor ?ELJTextDropTarget::ELJTextDropTarget(void*, int (*)(void*, long int, long int, void*))?: wxc/include/wrapper.h:209: error: class ?ELJTextDropTarget? does not have any field named ?wxTextDropTarget? wxc/include/wrapper.h: At global scope: wxc/include/wrapper.h:236: error: expected class-name before ?{? token wxc/include/wrapper.h:259: error: ?wxDragResult? does not name a type wxc/include/wrapper.h:261: error: ?wxDragResult? does not name a type wxc/include/wrapper.h:262: error: ?wxDragResult? does not name a type wxc/include/wrapper.h: In constructor ?ELJFileDropTarget::ELJFileDropTarget(void*, int (*)(void*, long int, long int, void*, int))?: wxc/include/wrapper.h:246: error: class ?ELJFileDropTarget? does not have any field named ?wxFileDropTarget? Can anyone help me? From allbery at ece.cmu.edu Tue Oct 28 13:08:18 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Oct 28 13:03:38 2008 Subject: [Haskell] How to get the binary respentation of the Int/Double. In-Reply-To: <200810282238493915117@163.com> References: <200810282238493915117@163.com> Message-ID: <92C23151-E985-445D-AC23-A5ABC4F6FAF7@ece.cmu.edu> On 2008 Oct 28, at 10:38, haihualin wrote: > I am wondering how to get the binary respentation of the Int/Double. > So I can save the integer as the binary data so that the C program > can read it from the file. The Binary package on Hackage (http://hackage.haskell.org) allows you to serialize Haskell data in any form including C-compatible binary output. -- 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 agocorona at gmail.com Tue Oct 28 18:26:10 2008 From: agocorona at gmail.com (Alberto G. Corona ) Date: Tue Oct 28 18:21:42 2008 Subject: [Haskell] ANNOUNCE: Data.TCache 0.5.1 Message-ID: I uploaded TCache to hackage.org. Data.Tcache is 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. There are transactional cache implementations for some J2EE servers like JBOSS. TCache uses STM . It can atomically apply a function to a list of cached objects. The resulting objects go back to the cache (withResources). It also can retrieve these objects (getResources). Persistence can be syncronous (syncCache) or asyncronous, wtih configurable time between cache writes and configurable cache clearance strategy. the size of the cache can be configured too . All of this can be done trough clearSyncCacheProc. Even the TVar variables can be accessed directly (getTVar) to acceess all the semantic of atomic blocks while maintaining the persistence of the TVar updates. Persistence can be defined for each object.: Each object must have a defined key, a default filename path (if applicable). Persistence is pre-defined in files, but the readResource writeResource and delResource methods can be redefined to persist in databases or whatever. There is a sample.hs that explain the main features. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20081028/c7143879/attachment.htm From twd2 at dockerz.net Wed Oct 29 07:09:02 2008 From: twd2 at dockerz.net (Tim Docker) Date: Wed Oct 29 07:04:14 2008 Subject: [Haskell] Announce: Chart-0.9 Message-ID: <57408.60.242.113.32.1225278542.squirrel@dockerz.net> Chart-0.9 is now available via hackage and a darcs repository. This is a library for drawing 2D charts. It relies upon the haskell cairo binding that is part of gtk2hs, and hence supports several backend output formats (png, pdf, ps, etc). Further information is available here: http://dockerz.net/software/chart.html Also, there is now a mailing list for discussions about the library: http://groups.google.com/group/haskell-charts Tim From dons at galois.com Wed Oct 29 14:04:22 2008 From: dons at galois.com (Don Stewart) Date: Wed Oct 29 13:59:47 2008 Subject: [Haskell] Announce: Chart-0.9 In-Reply-To: <57408.60.242.113.32.1225278542.squirrel@dockerz.net> References: <57408.60.242.113.32.1225278542.squirrel@dockerz.net> Message-ID: <20081029180422.GA25543@scytale.galois.com> twd2: > Chart-0.9 is now available via hackage and a darcs repository. > > This is a library for drawing 2D charts. It relies upon the haskell > cairo binding that is part of gtk2hs, and hence supports several > backend output formats (png, pdf, ps, etc). > > Further information is available here: > > http://dockerz.net/software/chart.html > > Also, there is now a mailing list for discussions about the library: > > http://groups.google.com/group/haskell-charts Available natively packaged for Arch, http://aur.archlinux.org/packages.php?ID=17735 -- Don From korcan_h at hotmail.com Wed Oct 29 19:56:43 2008 From: korcan_h at hotmail.com (Korcan Hussein) Date: Wed Oct 29 19:51:58 2008 Subject: [Haskell] =?windows-1256?q?Making_=27Super_Nario_Bros=2E=27_in_H?= =?windows-1256?q?askell=FE?= Message-ID: Hi I haven't seen this posted any where so I'm sorry in advance if this has been mentioned already but I came across this recent video on youtube: http://uk.youtube.com/watch?v=gVLFGQGRsDw it's a mario clone written in haskell with a link to source code repository (http://svn.coderepos.org/share/lang/haskell/nario/). I thought that it maybe useful to some people. Trustworthiness:Vendor reliability:Privacy:Child safety: _________________________________________________________________ Discover Bird's Eye View now with Multimap from Live Search http://clk.atdmt.com/UKM/go/111354026/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20081029/4503b612/attachment.htm From voigt at tcs.inf.tu-dresden.de Thu Oct 30 07:30:16 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Thu Oct 30 07:25:45 2008 Subject: [Haskell] LAST CALL: Haskell Communities and Activities Report Message-ID: <49099AC8.8010408@tcs.inf.tu-dresden.de> Dear Haskellers, It is not yet too late to contribute to the 15th edition of the HC&A Report. In fact, I will wait for a few more days. If you haven't already, please write an entry for your new project or update your old entry. Please mail your entries to hcar@haskell.org in plain text or LaTeX format. More information can be found in the original Call for Contributions at http://www.haskell.org/pipermail/haskell/2008-October/020651.html I look forward to receiving your contributions. Thanks a lot, Janis (current editor) -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From andres at cs.uu.nl Fri Oct 31 10:48:48 2008 From: andres at cs.uu.nl (Andres Loeh) Date: Fri Oct 31 10:43:55 2008 Subject: [Haskell] ANNOUNCE: multirec-0.1 Message-ID: <20081031144847.GL8028@cs.uu.nl> multirec: Generic programming with systems of recursive datatypes ================================================================= Many generic programs require information about the recursive positions of a datatype. Examples include the generic fold, generic rewriting or the Zipper data structure. Several generic programming systems allow to write such functions by viewing datatypes as fixed points of a pattern functor. Traditionally, this view has been limited to so-called regular datatypes such as lists and binary trees. In particular, systems of mutually recursive datatypes have been excluded. With the multirec library, we provide 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. We expect that the library will be especially interesting for compiler writers, because ASTs are typically systems of mutually recursive datatypes, and with multirec it becomes easy to write generic functions on ASTs. The library is based on ideas described in the paper: Alexey Rodriguez, Stefan Holdermans, Andres L?h, Johan Jeuring Generic programming with fixed points for mutually recursive datatypes Technical Report, Universiteit Utrecht http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-019.pdf Features -------- * Generalizes the fixed point view from single, regular datatypes to systems of recursive datatypes. * Includes detailed examples: generic fold and generic compos, the latter in the style of Bj?rn Bringert, Arne Ranta A pattern for almost compositional functions ICFP 2006 The Zipper and generic rewriting for systems of datatypes will be released soon as separate libraries that build on multirec. * The generic compos functions do not require the user to modify their existing systems of datatypes. * In its current form, this library does not support nested datatypes. Requirements ------------ * GHC 6.8.3 or later * Cabal 1.2.1 or later Download -------- With cabal-install: cabal install multirec Get the package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/multirec Get the source: svn checkout https://svn.cs.uu.nl:12443/repos/dgp-haskell/multirec/trunk Bugs & Support -------------- Report issues, request features, or just discuss the library with the authors, maintainers, and other interested persons at: http://www.haskell.org/mailman/listinfo/generics -- Andres Loeh, Universiteit Utrecht mailto:andres@cs.uu.nl mailto:mail@andres-loeh.de http://www.andres-loeh.de