- Haskell - Haskell.org

ANN: diagrams-0.6
by Brent Yorgey 12 Dec '12

12 Dec '12

I am pleased to announce the release of version 0.6 of diagrams [1], a full-featured framework and embedded domain-specific language for declarative drawing. Check out the gallery [2] for examples of what it can do! [3,4] [1] http://projects.haskell.org/diagrams [2] http://projects.haskell.org/diagrams/gallery.html [3] http://mathlesstraveled.com/2012/11/05/more-factorization-diagrams/ [4] http://projects.haskell.org/diagrams/gallery/PythagoreanTree.html Highlights of this release include: - Diagrams now comes with a native-Haskell SVG backend [5] by default. If you were holding off on trying diagrams because you couldn't install cairo, you no longer have an excuse! - Proper support for subdiagrams: previous versions of diagrams-core had a mechanism for associating names with a pair of a location and an envelope. Now, names are associated with actual subdiagrams (including their location and envelope, along with all the other information stored by a diagram). This enables cool techniques like constructing a diagram in order to position its subelements and then taking it apart again, or constructing animations via keyframing. - Traces: in addition to an envelope, each diagram now stores a "trace", which is like an embedded raytracer: given any ray (represented by a base point and a vector), the trace computes the closest point of intersection with the diagram along the ray. This is useful for determining points on the boundary of a diagram, e.g. when drawing arrows between diagrams. - The core data structure underlying diagrams has been completely refactored and split out into its own separate package, dual-tree [6]. - Support for GHC 7.6. - Many more new features, bug fixes, and improvements! See the release notes [7] for complete details, and the diagrams wiki [8] for help migrating from 0.5 to 0.6. [5] http://hackage.haskell.org/package/diagrams%2Dsvg [6] http://hackage.haskell.org/package/dual%2Dtree [7] http://projects.haskell.org/diagrams/releases.html Try it out ---------- For the truly impatient: cabal install diagrams Diagrams is supported under GHC 7.0 through 7.6, with the exception that the cairo and gtk backends do not build under GHC 7.0 (but the SVG backend does), and the gtk backend does not build under GHC 7.6. To get started with diagrams, read the quick tutorial [9], which will introduce you to the fundamentals of the framework. For those who are less impatient and want to really dig in and use the power features, read the user manual [10]. [8] http://www.haskell.org/haskellwiki/Diagrams/Migrate0.6 [9] http://projects.haskell.org/diagrams/tutorial/DiagramsTutorial.html [10] http://projects.haskell.org/manual/diagrams-manual.html Get involved ------------ Subscribe to the project mailing list [11], and/or come hang out in the #diagrams IRC channel on freenode.org for help and discussion. Make some diagrams. Fix some bugs [12]. Submit your cool examples for inclusion in the gallery [13] or your cool code for inclusion in the diagrams-contrib [14] package! [11] http://groups.google.com/group/diagrams-discuss [12] http://github.com/diagrams/ [13] http://projects.haskell.org/diagrams/gallery.html [14] http://hackage.haskell.org/package/diagrams%2Dcontrib Happy diagramming! Brought to you by the diagrams team: - Michael Sloan - Ryan Yates - Brent Yorgey with contributions from: - Sam Griffin - Niklas Haas - Peter Hall - Claude Heiland-Allen - Deepak Jois - John Lato - Felipe Lessa - Chris Mears - Ian Ross - Vilhelm Sjöberg - Jim Snavely - Luite Stegeman - Kanchalai Suveepattananont - Michael Thompson - Scott Walck

2 1

SCP Special Issue on Invariant Generation - Second Call for Papers [2 months to go]
by Gudmund Grov 10 Dec '12

10 Dec '12

(Apologies if you receive multiple copies of this announcement) ------------------------------------------------------------ Science of Computer Programming Special Issue on Invariant Generation -- SECOND CALL FOR PAPERS -- ------------------------------------------------------------ This special issue is devoted to the 4th international Workshop on Invariant Generation (WING 2012) http://cs.nyu.edu/acsys/wing2012/ which was held on June 30 2012 in Manchester as a satellite event of IJCAR 2012. The scope of the workshop is the automation of extracting and synthesising auxiliary properties of programs, in particular providing, debugging, and verifying auxiliary invariant annotations. This should be seen in a broad sense and relevant topics include (but are not limited to) the following: * Program analysis and verification * Inductive assertion generation * Inductive proofs for reasoning about loops * Applications to assertion generation using: - abstract interpretation, - static analysis, - model checking, - theorem proving, - theory formation, - algebraic techniques * Tools for inductive assertion generation and verification * Alternative techniques for reasoning about loops Submission to this special issue is completely open. We expect original articles (typically not more than 30 pages) that present high-quality contributions and must not be simultaneously submitted for publication elsewhere. Submission of extended versions of previously published papers is possible as long as the extension is significant, i.e., the submission can be considered a new paper, the previous paper is referenced, and the new material is clearly marked. Submissions must comply with SCP's author guidelines http://www.elsevier.com/wps/find/journaldescription.cws_home/505623/authori… and be written in English. Submission is over the SCP website: http://ees.elsevier.com/scico/default.asp which you will have to register for if you do not have an account. When submitting your paper please choose the article type "Special issue: WING 2012". IMPORTANT DATES --------------- * Submission of papers: February 11, 2013. * Notification: April 26, 2013. GUEST EDITORS -------------- * Gudmund Grov (Heriot-Watt University, UK) * Thomas Wies (New York University, USA) CONTACT -------------- Please send any queries you may have to: wing2012(a)easychair.org ----- Sunday Times Scottish University of the Year 2011-2013 Top in the UK for student experience Fourth university in the UK and top in Scotland (National Student Survey 2012) We invite research leaders and ambitious early career researchers to join us in leading and driving research in key inter-disciplinary themes. Please see www.hw.ac.uk/researchleaders for further information and how to apply. Heriot-Watt University is a Scottish charity registered under charity number SC000278.

1 0

ANNNOUNCE: lens 3.7 released
by Edward Kmett 10 Dec '12

10 Dec '12

Greetings! I am happy to announce the release of version 3.7 of the lens package, which provides "Lenses, Folds, and Traversals" for working with arbitrary data types. In its simplest form, a lens is a getter/setter pair, that can be composed and reasoned about with common sense laws that you can also derive from the Functor and Traversable laws you already know or even derive by reasoning in terms of comonad coalgebras for the even more theoretically inclined. The lens package provides lenses along with a surprisingly powerful set of generalizations and specializations of this idea, in a manner that subsumes the notion of a "semantic editor combinator", allowing you to enrich them with the ability to read back from the targets. In the form taken by the lenses in this package, lenses are empowered to safely change the types of the fields that they edit in a manner that not only can you still reason about, but where the changes in types helps you to reason about what they can or cannot do. One of the major design goals of lens has been that you should be able to pick up lens combinators and apply them meaningfully to a mishmash of lenses, traversals, isomorphisms, getters, and setters, etc. even without fully understanding all of the types. This encourages active exploration and users who are pleasantly surprised rather than frustrated and angry. To this end we've actively stocked the haddocks for the project with types it may be easier to think about each combinator as having, which can serve as training wheels that will help you make your way around. Most interestingly from a package maintainer perspective, unlike previous packages that provided lenses, it is possible to provide lenses (and traversals) that are compatible with the lens library without incurring any dependency for your package at all. For instance the simplest Traversal is traverse from Data.Traversable. traverse . traverse is also a valid Traversal, and it can be composed with other lenses and traversals without any casting or coercion. A large number of combinators are provided that automatically 'do the right thing' when presented with the various generalizations and specializations of the concept of a lens, e.g. when supplied a Traversal instead of a Lens, a combinator that returned a result based on the target of the Lens, may now return a monoidal summary of all of the results targered by the Traversal. Major Features: * Lenses, getters, setters, isomorphisms, folds, "prisms", monadic actions, and indexed versions of these constructions that can all be composed with (.) from the Prelude in a manner that they read quite naturally to an imperative programmer who expects (.) to be field access and to compose in the 'wrong' direction, while still retaining the ability to reason about the resulting code. * Type-safe zippers into arbitrary user data structures, where you can move down into a lens or laterally through a traversal and can come back up, following a breadcrumb trail in the type. * Lens contains a generalized version of Neil Mitchell's uniplate in such a way that the uniplate combinators themselves that many people already know how to use can be used on an arbitrary traversal, and uniplate/biplate simply act as a Traversal, and are often ~35% or more faster than the original. * Lens comes "batteries included" with classes and combinators for working with many common libraries that fall within the Haskell Platform. No dependencies are incurred that fall outside of the platform, unless those dependencies are needed to implement lens itself. * We provide configurable template-haskell generators for producing lenses, isomorphisms and traversals for your own data types. New in this release: * Prisms are categorically dual to Lenses and provide a form of first class pattern. They can be used directly as a Traversal. Many operations that formerly required an isomorphism can be used directly on a Prism, and every Isomorphism can be used as a Prism. * With this latest release we've incorporated a large amount of community feedback into the API design and have vastly expanded the documentation with hundreds of additional examples and test cases. * We've renamed a number of operations to reduce naming conflicts with third party libraries to a minimum, and improve consistency. in particular we no longer conflict with Control.Arrow. * We've overhauled the zipper API to permit easier use of multiple simultaneous zippers, and to make zipper movements more compositional. Resources: * Wiki <http://github.com/ekmett/lens/wiki/>: We have a FAQ<https://github.com/ekmett/lens/wiki/FAQ>, which includes a number of links to source material, a quick getting-started<https://github.com/ekmett/lens#examples> guide, a discussion of the Derivation<https://github.com/ekmett/lens/wiki/Derivation>, and even a UML diagram <https://github.com/ekmett/lens#field-guide> distributed among the other content of the wiki. If you find something missing or otherwise out of whack then feel free to edit it. =) * Larger Examples: We also have a number of larger examples<https://github.com/ekmett/lens/tree/master/examples> included in the lens distribution, including a fully operational game of Pong that plays using Gloss and a Brainfuck interpreter. * IRC: The #haskell-lens<http://webchat.freenode.net/?channels=haskell-lens&uio=d4>channel on irc.freenode.net is full of helpful people who work with or on lens itself. Lamdabot on #haskell has lens installed, and golfing solutions to user questions using lens as well as more traditional techniques has become disturbingly common. as * I gave a talk last month<http://google-opensource.blogspot.com/2012/10/lenses-folds-and-traversals-h…>at Google in San Francisco about "Lenses, Folds, and Traversals", and just under 100 people showed up. Sadly, this talk was not recorded. * However, I plan to give an updated version of that talk<http://www.meetup.com/NY-Haskell/events/91576512/>at the New York Haskell User Group <http://www.meetup.com/NY-Haskell/> meeting on Wednesday, December 12th from 7:00-9:00PM. At the time of this writing we have 94 slated as coming and room for 26 more, so if you'll be in the New York area on the 12th and are interested, register soon. =) That said, this time the talk will be recorded and the video will be made available online, so even if you can't make it out, you can still enjoy the talk. Support: * We currently support the last 3 versions of the Haskell Platform, including versions of GHC back to 7.0.4 and are actively maintaining the project as part of stackage <https://github.com/fpco/stackage>. We intend to maintain support for a rolling wave of at least 2 previous Haskell Platform releases going forward. * If you have any questions or comments, please feel free to contact me by email, github, or IRC. -Edward

2 2

CfP: Conf. Rewriting Techniques and Applications RTA 2013 -- deadline February 1
by Johannes Waldmann 07 Dec '12

07 Dec '12

RTA http://rta2013.few.vu.nl/cfp.html Deadline: February 1, Conference: June 24-26, Eindhoven NL Dear all, instead of copying the complete CfP, I'd like to specifically address the Haskell community: There are strong connections between (functional) programming and rewriting. For example, the execution of a program is a form of graph rewriting; the type checker rewrites type expressions; the code generator rewrites the program (for optimization). The conference on Rewriting Techniques and Applications is the major forum for the exchange of new ideas on all matters related to rewriting, covering the whole range from foundations to applications. And you should take the opportunity to contribute your ideas. Note: If you = Simon Peyton Jones, then you are the invited speaker. Else, follow the usual process of submitting a paper by February 1. Best regards, on behalf of the RTA programme committee, Johannes Waldmann.

1 0

The end of an era, and the dawn of a new one
by Simon Peyton-Jones 06 Dec '12

06 Dec '12

Friends You'll have seen Simon Marlow's recent announcement (included below): | Today I'm announcing that I'm leaving Microsoft Research. Simon Marlow and I have worked together on GHC for nearly two decades. During much of that time we have shared a cup of coffee every morning (one cup each, since you ask), to discuss what's going on in GHC-land. We had frequent detailed and illuminating debates about design alternatives. Simon is the absolute master of GHC's code generation, runtime system, garbage collector, support for parallel execution, and much else besides. His sheer programming skill in rooting out obscure and hard-to-reproduce runtime system bugs has always amazed me. He is more than just a great hacker, of course. He is a leader in our community, has a strong publication record, chaired the Haskell Prime committee for a year, and is sought after for tutorials about parallel programming. I owe Simon a great debt, as I think we all do, for the care and skill he has lavished on GHC. He's not going to disappear entirely, but he will be spending much less time on GHC than in the past. That is a change, but it's a change that was always going to happen sometime, and while change is sometimes uncomfortable, it can also open up new possibilities. GHC is over 20, and like my own children (who are actually all a bit younger than GHC), that's not a bad time to start to head out into the world. Over time, more and more people have started to help with the task of developing and maintaining GHC. We'll have to do more of that. These days GHC has a very large "surface area" (running on different platforms, dynamic linking, debugger, profiler, GHCi, libraries and Cabal, etc etc), and has grown far beyond what any single person or research group can manage. Lest you should wonder, I myself will certainly continue to work on GHC. But my job is to be a *researcher*, and I am not well equipped -- in temperament or expertise -- to deal with the myriad complexities of deployment, upgrade policy, portability, and the like. Well Typed (mostly in the guise of Ian Lynagh) will continue to handle some of these issues, but again there is too much for one person to do. So we need your help. Seriously. Rather than just thinking "GHC HQ will sort it out", I would welcome you saying "Shall I take responsibility for X?". Johan, Bryan, and others offering to be GHC Performance Tsars is a great recent example. But don't wait to be asked: just make an offer if you see a gap or an open ticket --- and I think there will be plenty of those. Particularly valuable are offers to take responsibility for a particular area (eg the LLVM code generator, or the FFI). I'm hoping that this sea change will prove to be quite empowering, with GHC becoming more and more a community project, more resilient with fewer single points of failure. I am going to miss that cup of coffee though. Thank you Simon! Facebook is lucky to have you. Onward and upward. Simon (PJ) | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell- | users-bounces(a)haskell.org] On Behalf Of Simon Marlow | Sent: 22 November 2012 11:27 | To: haskell; glasgow-haskell-users(a)haskell.org | Subject: Leaving Microsoft | | Today I'm announcing that I'm leaving Microsoft Research. | | My plan is to take a break to finish the book on Parallel and Concurrent | Haskell for O'Reilly, before taking up a position at Facebook in the UK | in March 2013. | | This is undoubtedly a big change, both for me and for the Haskell | community. I'll be stepping back from full-time GHC development and | research and heading into industry, hopefully to use Haskell. It's an | incredibly exciting opportunity for me, and one that I hope will | ultimately be a good thing for Haskell too. | | What does this mean for GHC? Obviously I'll have much less time to work | on GHC, but I do hope to find time to fix a few bugs and keep things | working smoothly. Simon Peyton Jones will still be leading the project, | and we'll still have support from Ian Lynagh, and of course the | community of regular contributors. Things are in a reasonably stable | state - there haven't been any major architectural changes in the RTS | lately, and while we have just completed the switchover to the new code | generator, I've been working over the past few weeks to squeeze out all | the bugs I can find, and I'll continue to do that over the coming months | up to the 7.8.1 release. | | In due course I hope that GHC can attract more of you talented hackers | to climb the learning curve and start working on the internals, in | particular the runtime and code generators, and I'll do my best to help | that happen. | | Cheers, | Simon

2 1

Haskell Weekly News: Issue 253
by Daniel Santa Cruz 06 Dec '12

06 Dec '12

Welcome to issue 253 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers the week of November 25 to December 01, 2012. Quotes of the Week * edwardk: this breaks my previous record of 6 unsafeCoerce's in a line * bos:Harpers gona harp. Top Reddit Stories * Pretty Output in GHCi (HOWTO in comments) Domain: i.imgur.com, Score: 82, Comments: 14 On Reddit: [1] http://goo.gl/2c7Ns Original: [2] http://goo.gl/uYZAs * Stable, Vetted Hackage: Call for Participation Domain: yesodweb.com, Score: 59, Comments: 24 On Reddit: [3] http://goo.gl/QrJEz Original: [4] http://goo.gl/1PlBK * Strict vs non-strict semantics: "Why can’t I just be a little lazy?" Domain: blog.ezyang.com, Score: 42, Comments: 20 On Reddit: [5] http://goo.gl/P2nSm Original: [6] http://goo.gl/WDhk6 * io-stream: simple and easy to use primitives for I/O using streams Domain: github.com, Score: 37, Comments: 10 On Reddit: [7] http://goo.gl/uDbGG Original: [8] http://goo.gl/sGqtY * Toward a Secret Sky: Building a Haskell web app with Snap: Snap quickstart guide Domain: unpythonic.blogspot.ca, Score: 36, Comments: 15 On Reddit: [9] http://goo.gl/6UdY8 Original: [10] http://goo.gl/Y6wli * Hackage: unittyped-0.1, an extendable library for type-safe computations including units Domain: hackage.haskell.org, Score: 34, Comments: 23 On Reddit: [11] http://goo.gl/f7b1M Original: [12] http://goo.gl/jmZCi * Easy JSON parsing in Haskell with Aeson Domain: blog.raynes.me, Score: 34, Comments: 18 On Reddit: [13] http://goo.gl/JERS0 Original: [14] http://goo.gl/Ccfbm * 1st São Paulo Haskell Meeting Domain: plus.google.com, Score: 29, Comments: 4 On Reddit: [15] http://goo.gl/MKVPb Original: [16] http://goo.gl/yaLUi * Conal Elliott: "Parallel speculative addition via memoization" Domain: conal.net, Score: 26, Comments: 11 On Reddit: [17] http://goo.gl/EQZxj Original: [18] http://goo.gl/wg0KD * Elm: Making the Web Functional [video/slides] Domain: infoq.com, Score: 26, Comments: 1 On Reddit: [19] http://goo.gl/0qAJM Original: [20] http://goo.gl/bldR0 * From traced monoidal to compact closed: geometry of interaction explained with (OCaml) code Domain: semantic-domain.blogspot.fr, Score: 18, Comments: 22 On Reddit: [21] http://goo.gl/auq1p Original: [22] http://goo.gl/4XvRw * Static Analysis with Applicatives Domain: gergo.erdi.hu, Score: 17, Comments: 13 On Reddit: [23] http://goo.gl/sNLm9 Original: [24] http://goo.gl/Lvxpn * 24 Pull Requests - Does Anyone Have Project Suggestions? Domain: self.haskell, Score: 16, Comments: 3 On Reddit: [25] http://goo.gl/U2bsY Original: [26] http://goo.gl/U2bsY * what if haskell-platform was a hackage metapackage? Domain: self.haskell, Score: 16, Comments: 7 On Reddit: [27] http://goo.gl/SPIlO Original: [28] http://goo.gl/SPIlO * Does anyone know if more videos are going to be posted to Haskell Live TV? Domain: youtube.com, Score: 15, Comments: 2 On Reddit: [29] http://goo.gl/jJxWb Original: [30] http://goo.gl/NVk3D * Data-driven hacks for DB querying — is this evil? Domain: hpaste.org, Score: 13, Comments: 22 On Reddit: [31] http://goo.gl/0J5eJ Original: [32] http://goo.gl/gfRLS * Why does this result not appear in this search in Hoogle? Domain: self.haskell, Score: 12, Comments: 10 On Reddit: [33] http://goo.gl/DGTu2 Original: [34] http://goo.gl/DGTu2 Top StackOverflow Questions * Is putStrLn thread-safe? votes: 12, answers: 1 Read on SO: [35] http://goo.gl/rjRyN * How do you prove that a function is unique for its type? votes: 11, answers: 1 Read on SO: [36] http://goo.gl/odOSy * Laziness/strictness between data and newtype votes: 10, answers: 2 Read on SO: [37] http://goo.gl/Dkqv8 * Why do we use folds to encode datatypes as functions? votes: 10, answers: 1 Read on SO: [38] http://goo.gl/RRVuE * Haskell repa - how to reduce array and return index? votes: 7, answers: 2 Read on SO: [39] http://goo.gl/HpXhR * How much is applicative really about applying, rather than “combining”? votes: 7, answers: 1 Read on SO: [40] http://goo.gl/zq6j3 * Why is that not lazy votes: 7, answers: 2 Read on SO: [41] http://goo.gl/F8H0m * Biapplicative and Bimonad? votes: 6, answers: 1 Read on SO: [42] http://goo.gl/7C01J * reactive-banana-wx `sink` does not generate an event enabling post-sink processing votes: 6, answers: 1 Read on SO: [43] http://goo.gl/pXdTu * Expand type synonyms, type families with GHCi votes: 6, answers: 1 Read on SO: [44] http://goo.gl/G6Sks * Converting expression to pointfree style (Haskell) votes: 6, answers: 1 Read on SO: [45] http://goo.gl/36gLO * ADTs vs. Typeclasses — Canonical use votes: 6, answers: 1 Read on SO: [46] http://goo.gl/ofpbX * Haskell: Monitor a file without polling (à la inotify in linux) votes: 6, answers: 3 Read on SO: [47] http://goo.gl/JGzI0 Until next time, Daniel Santa Cruz References 1. http://i.imgur.com/t6hOx.png 2. http://www.reddit.com/r/haskell/comments/144biy/pretty_output_in_ghci_howto… 3. http://www.yesodweb.com/blog/2012/11/stable-vetted-hackage 4. http://www.reddit.com/r/haskell/comments/141hww/stable_vetted_hackage_call_… 5. http://blog.ezyang.com/2012/11/why-cant-i-just-be-a-little-lazy/ 6. http://www.reddit.com/r/haskell/comments/13tt44/strict_vs_nonstrict_semanti… 7. https://github.com/snapframework/io-streams 8. http://www.reddit.com/r/haskell/comments/13z9i4/iostream_simple_and_easy_to… 9. http://unpythonic.blogspot.ca/2012/11/building-haskell-web-app-with-snap-sn… 10. http://www.reddit.com/r/haskell/comments/13sb85/toward_a_secret_sky_buildin… 11. http://hackage.haskell.org/package/unittyped-0.1 12. http://www.reddit.com/r/haskell/comments/13t795/hackage_unittyped01_an_exte… 13. http://blog.raynes.me/blog/2012/11/27/easy-json-parsing-in-haskell-with-aes… 14. http://www.reddit.com/r/haskell/comments/141ch4/easy_json_parsing_in_haskel… 15. https://plus.google.com/events/cng3rcv1tjl84g2juddk1i36icg 16. http://www.reddit.com/r/haskell/comments/13vctv/1st_s%C3%A3o_paulo_haskell_… 17. http://conal.net/blog/posts/parallel-speculative-addition-via-memoization 18. http://www.reddit.com/r/haskell/comments/13yenz/conal_elliott_parallel_spec… 19. http://www.infoq.com/presentations/Elm 20. http://www.reddit.com/r/haskell/comments/1423uc/elm_making_the_web_function… 21. http://semantic-domain.blogspot.fr/2012/11/in-this-post-ill-show-how-to-tur… 22. http://www.reddit.com/r/haskell/comments/13zzxl/from_traced_monoidal_to_com… 23. http://gergo.erdi.hu/blog/2012-12-01-static_analysis_with_applicatives 24. http://www.reddit.com/r/haskell/comments/143wpd/static_analysis_with_applic… 25. http://www.reddit.com/r/haskell/comments/143c0e/24_pull_requests_does_anyon… 26. http://www.reddit.com/r/haskell/comments/143c0e/24_pull_requests_does_anyon… 27. http://www.reddit.com/r/haskell/comments/1445jh/what_if_haskellplatform_was… 28. http://www.reddit.com/r/haskell/comments/1445jh/what_if_haskellplatform_was… 29. http://www.youtube.com/user/HaskellLiveTV 30. http://www.reddit.com/r/haskell/comments/13x0z9/does_anyone_know_if_more_vi… 31. http://hpaste.org/78401 32. http://www.reddit.com/r/haskell/comments/13xi63/datadriven_hacks_for_db_que… 33. http://www.reddit.com/r/haskell/comments/13r9ii/why_does_this_result_not_ap… 34. http://www.reddit.com/r/haskell/comments/13r9ii/why_does_this_result_not_ap… 35. http://stackoverflow.com/questions/13549706/is-putstrln-thread-safe 36. http://stackoverflow.com/questions/13575583/how-do-you-prove-that-a-functio… 37. http://stackoverflow.com/questions/13566673/laziness-strictness-between-dat… 38. http://stackoverflow.com/questions/13575894/why-do-we-use-folds-to-encode-d… 39. http://stackoverflow.com/questions/13570354/haskell-repa-how-to-reduce-arra… 40. http://stackoverflow.com/questions/13625905/how-much-is-applicative-really-… 41. http://stackoverflow.com/questions/13663430/why-is-that-not-lazy 42. http://stackoverflow.com/questions/13556314/biapplicative-and-bimonad 43. http://stackoverflow.com/questions/13580121/reactive-banana-wx-sink-does-no… 44. http://stackoverflow.com/questions/13595773/expand-type-synonyms-type-famil… 45. http://stackoverflow.com/questions/13596335/converting-expression-to-pointf… 46. http://stackoverflow.com/questions/13610164/adts-vs-typeclasses-canonical-u… 47. http://stackoverflow.com/questions/13642619/haskell-monitor-a-file-without-…

1 0

Re: [Haskell] The end of an era, and the dawn of a new one
by Johan Tibell 05 Dec '12

05 Dec '12

On Wed, Dec 5, 2012 at 12:37 PM, David Terei <davidterei(a)gmail.com> wrote: > I have always considered the LLVM code generator my responsibility and > will continue to do so. I don't seem to find the time to make > improvements to it but make sure to keep it bug free and working with > the latest LLVM releases. So if others want are interested in working > on it then there is plenty of room for that but I'll continue to > maintain it and be responsible for it at the least. I will maintain the I/O manager as per usual, probably together with Bryan and Andreas (but I cannot speak for them of course).

1 0

FINAL CFP PLACES'13 -- Deadline for Abstracts Fri 14 Dec, full papers Fri 21 Dec
by Wim Vanderbauwhede 05 Dec '12

05 Dec '12

FINAL CALL FOR PAPERS PLACES'13 Programming Language Approaches to Concurrency and Communication-cEntric Software 23rd March 2013, Rome, Italy (affiliated with ETAPS 2013) http://places13.di.fc.ul.pt/ ** Important Dates ** Abstract (title & abstract): 14th December 2012 Paper Submission (up to 5 pages): 21st December 2012 Paper Notification: 23rd January 2012 Final versions of papers: 4th February 2012 ** Background ** Applications today are built using numerous interacting services; soon off-the-shelf CPUs will host thousands of cores, and sensor networks will be composed from a large number of processing units. Many applications need to make effective use of thousands of computing nodes. At some level of granularity, computation in such systems is inherently concurrent and communication-centred. To exploit and harness the richness of this computing environment, designers and programmers will utilise a rich variety of programming paradigms, depending on the shape of the data and control flow. Plausible candidates for such paradigms include structured imperative concurrent programming, stream-based programming, concurrent functions with asynchronous message passing, higher-order types for events, and the use of types for communications and data structures (such as session types and linear types), to name but a few. Combinations of these abstractions will be used even in a single application, and the runtime environment needs to ensure seamless execution without relying on differences in available resources such as the number of cores. The development of effective programming methodologies for the coming computing paradigm demands exploration and understanding of a wide variety of ideas and techniques. This workshop aims to offer a forum where researchers from different fields exchange new ideas on one of the central challenges for programming in the near future, the development of programming methodologies and infrastructures where concurrency and distribution are the norm rather than a marginal concern. ** Topics of Interest ** Submissions are invited in the general area of foundations of programming languages for concurrency, communication and distribution. Specific topics include: * language design and implementations for communications and/or concurrency, * session types, * concurrent data types, * concurrent objects and actors, * multicore programming, * use of message passing in systems software, * interface languages for communication and distribution, * program analysis, * web services, * novel programming methodologies for sensor networks, * integration of sequential and concurrent programming, * high-level programming abstractions for security concerns in concurrent, distributed programming, * runtime architectures for concurrency, * scalability and/or resource allocations. Papers are welcome which present novel and valuable ideas as well as experiences. ** Submission Guidelines ** Authors should submit a title and an abstract by Wednesday 14th December 2012. Papers of up to *five pages* in length should be submitted in PDF format by Wednesday 21st December 2012 using the EasyChair proceedings template available at: http://www.easychair.org/easychair.zip Abstracts and papers should be submitted using EasyChair: http://www.easychair.org/conferences/?conf=places2013 Preliminary proceedings will be available at the workshop. The post proceeding will be published as an EPTCS volume. Note that, as we accept short papers, extended versions of the accepted works could be also submitted elsewhere. Enquiries can be sent to the PC co-chairs. ** Program Committee ** Alastair Beresford, University of Cambridge, UK Viviana Bono, Universita di Torino, Italy Alastair Donaldson, Imperial College London, UK Dan Ghica, University of Birmingham, UK Joshua Guttman, Worcester Polytechnic Institute, MA, US Thomas Hildebrandt, University of Copenhagen, Denmark Paul Keir, Codeplay Ltd, UK Hans-Wolfgang Loidl, Heriot-Watt University, UK Conor McBride, University of Strathclyde, UK Jeremy Singer, University of Glasgow, UK Sven-Bodo Scholz, Heriot-Watt University, UK Nikhil Swamy, Microsoft Research, US Wim Vanderbauwhede (co-chair), University of Glasgow, UK Hugo Torres Vieira, Universidade de Lisboa, Portugal Nobuko Yoshida (co-chair), Imperial College London, UK ** Organizing Committee ** Alastair Beresford, University of Cambridge, UK Simon Gay, University of Glasgow, UK Alan Mycroft, University of Cambridge, UK Vasco Vasconcelos, University of Lisbon, Portugal Nobuko Yoshida, Imperial College London, UK

1 0

Haskell from Glorious Kingdom
by Henning Thielemann 04 Dec '12

04 Dec '12

Hi Haskellers, since it is Advent time you might like to listen to a song that I programmed and performed with the Haskell Live-Sequencer [1]: http://www.youtube.com/watch?v=O5k0wUh0lj8 and you might want to check the Live-Sequencer, too. The Live-Sequencer allows to compose songs in Haskore style interactively. The most important feature is that you may alter the running program/song and that you can do so together with many people via network. Best, Henning [1] http://www.haskell.org/haskellwiki/Live-Sequencer

2 1

Re: [Haskell] Status of Haskell'?
by Gábor Lehel 01 Dec '12

01 Dec '12

On Fri, Nov 30, 2012 at 11:06 PM, Nate Soares <nate(a)so8r.es> wrote: > >> This standardization process amounts to "endorsement of existing >> features" which seems like not a bad process at all. It makes >> the standard descriptive rather than predictive. > > > +1. I agree generally with Gabor's points -- GHC is in the drivers seat. But > at some point we should take a look at all the things GHC has made that did > pay off and that are good and make them official. > > I'd very much like to see that endorsement happen soon, even if it's not > aggressive. Well, I'm not so sure it's a great idea to just bake "what GHC does at this moment" (for any particular extension) into the standard without really thinking about it. Even then, you have to figure out, in great detail, what GHC does, and write it all down! That's not negligible effort, either. And the alternative is to also publicly discuss and hash all of it out down to the little tiny gritty stuff. But wanting to write a new standard (big effort!) just to get rid of some pragmas and make people feel better (small payoff!) feels like a mismatch to me. Maybe as some kind of useful in-between point, the GHC folks could figure out which extensions they like enough that they would, modulo all the details getting figured out and specified, be in favor of them going into a new standard, and fold all of them into a new LANGUAGE definition? So then you would write {-# LANGUAGE HaskellNext #-}, or HaskellGHC, or something like that, to enable all of them in one go. That wouldn't require specifying things down to the tiniest details (which is what a standard requires), but only at the granularity of particular extensions, which is what people seem to be looking for. Maybe instead of the GHC people deciding it, there could be some kind of community process (such as a vote). (And yeah, this sounds eerily similar to -fglasgow-exts, which is what we got rid of in favor of LANGUAGE pragmas, but maybe the fact that -fglasgow-exts turned mostly all extensions on indiscriminately, whereas this would be a curated subset, is a significant enough difference to turn it from a bad idea into a good one.) -- Your ship was destroyed in a monadic eruption.

5 6