Index

This is the 25th edition of the Haskell Communities and Activities Report. As usual, fresh entries are formatted using a blue background (there are a lot of those by a single person this time around; guess by whom), while updated entries have a header with a blue background. Entries on which no new activity has been reported for a year or longer have been dropped completely. Please do revive such entries next time if you do have news on them.

A few words from Janis: This is the last instance of HCAR in which I have a hand as editor. It’s been a few years, and I am happy that Mihai has stepped in to continue the work of putting together editions of the report, and will be joined by Alejandro Serrano Mena next time around. Thanks to everybody for support in the last years. And thanks to Mihai and Alejandro for taking over; now it’s your turn to evoke guilty feelings in your fellow Haskellers: http://ro-che.info/ccc/16.html.

A call for new HCAR entries and updates to existing ones will be issued on the Haskell mailing lists in April. Now enjoy the current report and see what other Haskellers have been up to lately. Any feedback is very welcome, as always.

Janis Voigtländer, University of Bonn, Germany

Mihai Maruseac, University of Massachusetts Boston, US

<hcar at haskell.org>

The source for the Haskell report will be updated as proposals are accepted, but new versions of the standard will only be released once a year, during January.

So if you have been meaning to put the finishing touches to a proposal, then we would encourage you to do so by the end of July!

The Haskell 2014 committee has now formed, and we would be delighted to receive your proposals for changes to the language. Please see http://hackage.haskell.org/trac/haskell-prime/wiki/Process for details on the proposal process.

Haskell’ is an ongoing process to produce revisions to the Haskell standard, incorporating mature language extensions and well-understood modifications to the language. New revisions of the language are expected once per year.

Haskellers remains a site intended for all members of the Haskell community, from professionals with 15 years experience to people just getting into the language.

Since the May 2011 HCAR, Haskellers has added polls, which provides a convenient means of surveying a large cross-section of the active Haskell community. There are now over 1300 active accounts, versus 800 one year ago.

Haskellers is a site designed to promote Haskell as a language for use in the real world by being a central meeting place for the myriad talented Haskell developers out there. It allows users to create profiles complete with skill sets and packages authored and gives employers a central place to find Haskell professionals.

Since the last HCAR there has been one new issue, featuring tutorials on generalized algebraic data types, monad transformers, and approximating NP-complete problems with monoids.

The Monad.Reader is also a great place to write about a tool or application that deserves more attention. Most programmers do not enjoy writing manuals; writing a tutorial for The Monad.Reader, however, is an excellent way to put your code in the limelight and reach hundreds of potential users.

There are plenty of interesting ideas that might not warrant an academic publication—but that does not mean these ideas are not worth writing about! Communicating ideas to a wide audience is much more important than concealing them in some esoteric journal. Even if it has all been done before in the Journal of Impossibly Complicated Theoretical Stuff, explaining a neat idea about “warm fuzzy things” to the rest of us can still be plain fun.

There are many academic papers about Haskell and many informative pages on the HaskellWiki. Unfortunately, there is not much between the two extremes. That is where The Monad.Reader tries to fit in: more formal than a wiki page, but more casual than a journal article.

We encode the statement of the problem as a filter on possible worlds. The possible worlds consistent with the statement of the problem are the solutions. “Agent |A| does not know proposition phi” is interpreted as the statement that for all worlds consistent with the propositions that |A| currently knows, phi is true in some worlds but false in the others.

The article presents a simplistic model-theoretic framework to solve the puzzles like the following:

|DecidableInstances| are quite like the primitive recursion criterion: all primitive recursive functions surely terminate; non-primitive recursive functions generally don’t. Still there are many classes of non-primitive recursive functions that are total.

However, the decidability conditions are sufficient but by no means necessary to ensure the decidability of type normalization. There are patently decidable type programs that require |UndecidableInstances|. This article shows a simple example, and argues for more acceptance towards |UndecidableInstances|. The extension never causes the type-checker to accept a program that ‘goes wrong.’ It should not be categorically stigmatized.

Class instance and type family instance declarations are subject to a set of strict conditions that ensure the termination of resolving class constraints or normalizing type function applications. The conditions are quite constrictive, and GHC offers a way to lift them, with the |LANGUAGE| pragma |UndecidableInstances|. The pragma is shunned however. There are good reasons for that attitude: the pragma lets us write instances that send the type checker into infinite loop (albeit only potentially: the termination is insured by the recursion depth limit).

Uncharitably speaking, Haskell, taken as a logic, is inconsistent in more than two ways.

Value-level recursion in Haskell is built-in since definitions are implicitly recursive. Had the value-level recursion been unavailable, we could still safely define the polymorphic fix-point combinator in Haskell – in five different ways. Iso-recursive data types are a well-known way to |fix|. Less known is using type classes or families. The lazy |ST| approach is most puzzling: the reading of a reference cell appears to occur in pure code.

The collection of various Haskell mini tutorials and assorted small projects ( http://okmij.org/ftp/Haskell/ ) has received three additions:

I currently work on the correction and completion of the existing material.

The main goal of the tutorial is to let people explore programming in Agda without learning theoretical background in advance. Only secondary school mathematics is required for the tutorial.

Agda may be the next programming language to learn after Haskell. Learning Agda gives more insight into the various type system extensions of Haskell, for example.

All Haskell programmers are encouraged to visit the School of Haskell and to contribute their ideas and projects. This is another opportunity to showcase the virtues of Haskell and the sophistication and high level thinking of the Haskell community.

The School of Haskell is an excellent resource for Haskell developers looking to share their projects and to become more proficient with Haskell. So far 1400 tutorials have been created and 288 have been officially published. Some very notable authors including, Edward Kmett, Michael Snoyman, and Simon Peyton Jones have contributed tutorials. To date, the school of Haskell has had nearly 25k unique visitors.

Strides are being made to drive greater Haskell adoption. One resource helping with this push is the School of Haskell at FP Complete. The School of Haskell contains tutorials, courses, and articles created by both the Haskell community and the developers at FP Complete. Courses for all levels of developers are available and since going live in early 2013, it has benefited immensely from a lot of excellent content provided by the Haskell community.

The GHC 7.8 release is in its final stages, and will be released in late November according to our plans. There’s a tremendous amount of exciting changes coming very soon, described below.

In light of this, Well-Typed has added two people to GHC HQ to keep things moving, and help the development process going forward: Edsko de Vries and Austin Seipp .

While Ian has not completely disappeared, GHC and Haskell are not his day-job anymore. As a result, this means everyone — including you, our friend and reader — have a huge opportunity to help continue making GHC even better. Luckily, the past few months of activity points towards a tremendous surge in community involvement. GHC is a community project, and the community is what keeps us afloat. A great thanks goes to all those who have helped us come so far!

A big event occurred earlier this year in July: the news that Ian Lynagh would be leaving Well-Typed — and consequently, GHC HQ — to move onto new challenges. Ian worked on GHC for 7 years full-time, helped write our new build system, redesigned large parts of the compiler, and fixed innumerable other issues over the course of his work with us. According to some statistics for the past 7 years or so [Contr], Ian quite clearly is one of the biggest contributors we’ve ever had. And we should take the time to say what is rightfully deserved: thank you for everything you’ve done for us, Ian!

to express that |Flip| may have no more instances written, meaning nefarious users can no longer write silly instances like |Flip Bool = Int|.

GHC now tells us that the term |f| has a hole of type |a|, and there is a term |x :: a| in scope. So the definition is clear: |f x = x|. Holes are originally a concept borrowed from Agda, and we hope they will be useful to Haskell programmers too!

Prelude> :set -XTypeHoles Prelude> let f :: a -> a; f x = _ <interactive>:6:24: Found hole '_' with type: a Where: 'a' is a rigid type variable bound by the type signature for f :: a -> a at <interactive>:6:10 Relevant bindings include x :: a (bound at <interactive>:6:20) f :: a -> a (bound at <interactive>:6:18) In the expression: _ In an equation for 'f': f x = _

|-XOverloadedLists| which allows overloading list literals (Achim Krause, George Giorgidze, Weijers Jeroen)

|-XNumDecimals| allowing a compact floating-point syntax for integrals, e.g. |1.2e6 :: Integer| (Shachaf Ben-Kiki)

Support for empty case statements (via |-XEmptyCase|, by Richard Eisenberg)

|-XIncoherentInstances| became even more liberal (Joachim Breitner)

A new pragma for specifying the minimal complete definition of a typeclass, via |-# MINIMAL #-| (Twan van Laarhoven)

Back end and runtime system:

New code generator. As previously reported, the New Code Generator is live and switched on by default. There have been a host of bugfixes and stability improvements, meaning it should be solid for the 7.8 release. SSE/AVX support. Geoffrey Mainland implemented support for SSE/AVX intrinsics in the compiler backend, making it possible to exploit hardware-accelerated SIMD operations in your code on Intel/AMD machines. It’s currently only enabled for the LLVM backend, however. LLVM back end. Peter Wortmann spent time earlier this year doing a significant refactoring of the LLVM backend, which means it should be easier in the future to extend the backend and perform long-term maintenance. Code generation. Jan Stolarek had an internship at Microsoft Research during the summer, and as part of this he implemented an array of improvements to the code generator and backend, including a new loopification pass to turn tail-recursive calls into loops, and a refactoring of our |Bool| based primops to return unboxed |Int#| values (making them much faster, with a sizeable performance improvement in some cases [PrimBool].) Unloading object code. Simon Marlow implemented support for unloading object code at runtime in the GHC linker. Previously, while GHC’s linker could load object code dynamically, there was no facility to unload it — meaning long running applications would continuously suffer a memory leak as they reloaded more code. Library constructors. Edward Yang implemented support for running library constructors in GHCi, making it possible to use foreign libraries which depend on constructors being run at load time. Atomic and prefetch primops. There are new primops for all backends, including new atomic memory operations (by Ryan Newton) and support for low-level prefetch instructions in the processor, allowing you to guide cache decisions (by Carter Schonwald.)

Frontend, build-system, and miscellaneous changes:

Dynamic-by-default. In 7.8, we’re hoping to make GHCi use the system linker by default on supported platforms, eliminating a host of bugs in the current home-grown linker. Eventually we hope to remove the old linker completely. Until then, GHC now supports compiling files statically and dynamically at the same time (with the -dynamic-too flag,) meaning you can switch between static/dynamic builds much more easily. Compiler hooks. Luite Stegeman and Edsko de Vries did a significant amount of work to improve hooking support in the GHC API. This new API makes it possible for users to plug in their own pipeline machinery to the compiler, suitable for implementing new frontend features (like QuasiQuoting hooks) or new backends (like a JavaScript target, as part of the new GHCJS.) Parallel --make . As part of the haskell.org 2013 GSoC, Patrick Palka implemented a new parallel compilation driver, a long-requested feature. This allows GHC to build multiple modules in parallel when using --make by adding a -j flag, while having almost no overhead in the single-threaded case. Clang support. Austin Seipp added support for GHC to use Clang as the C compiler, instead of GCC. While the work is still rough, it should be a boon to modern OS X users, who no longer have GCC available by default. iOS support and cross compilation. After many years of work by Ian, Stephen Blackheath, Gabor Greif and friends Luke Iannini and Maxwell Swadling, GHC now has full support for iOS cross-compilation. As of GHC 7.8, you’ll really be able to write iOS apps in your favorite programming language! Better ARM support. Ben Gamari and Austin Seipp have some final changes to make for the ARM story, which should make it significantly more stable and usable, including GHCi support. We hope to have ARMv7 binary releases for GHC 7.8 available for download.

Future plans:

After the 7.8 release, there are some improvements scheduled we plan on integrating:

Applicative as a superclass of Monad. A long-standing proposal, GHC 7.10 will finally make |Applicative| a superclass of |Monad|. GHC 7.8 features warnings to ensure users know where their code will break as a result of this API change. Kinds without data. Trevor Elliott, Eric Mertens, and Iavor Diatchki have began implementing support for ‘data kind’ declarations, described in more detail on the GHC wiki [KD]. The idea is to allow a new form of declaration that introduces a new kind, whose members are described by the (type) constructors in the declaration. This is similar to promoting data declarations, except that no new value-level-constructors are declared, and it also allows the constructors to mention other kinds that do not have corresponding type-level representation (e.g., * ). Overloaded record fields. Adam Gundry implemented the overloaded records field proposal as part of the Haskell.org 2013 GSoC. This work will make it possible to not only have overloaded record field names, but also enable a wealth of other nice features, like polymorphic update/lookup, and automatically turning record fields into lens (→7.1.2). More detail can be found on the GHC wiki [ORF]. Pattern synonyms. GergöErdi worked on an implementation of pattern synonyms for GHC, which will finally give us the power to abstract over patterns and give them names. While the design is not final (see the wiki for details[PS]), the results look promising, and will hopefully fix a long-standing ‘abstraction hole’ in the term language for Haskell. Explicit Type Application. Stephanie Weirich, Richard Eisenberg and Hamidhasan Ahmed have been working on adding explicit type applications to GHC. This allows the programmer to specify the types that should be instantiated for arguments to a function application, where normally they would be inferred. While this capability already exists in GHC’s internal language, System FC — indeed, every FC-pro program has function application with explicitly applied types — it has not been available in Haskell itself. While a lot of the syntax and design is not quite final, there are some details about the design available on the wiki [TA]. Git management changes. For a long time, GHC has used a loosely coupled set of repositories during development. However, as we’ve added more contributors, this practice has become increasingly problematic, preventing us from using useful tools like git bisect to track down bugs. Our plans after the 7.8 release are to sort this out, and hopefully have stable, reproducible GHC builds for all. Continuous Integration overhaul. GHC has historically been very spotty about continuous integration. Part of the problem is our git management, mentioned above. In the 7.10 timeframe, we hope to spend a significant amount of time overhauling our buildbots and machines. To this end, Rackspace has graciously donated services as part of its Open Source support initiatives.

But we’re not sure what else might happen. It’s a great time to step up to the plate and do something fun!

Development updates, joining in and a big Thank You!

In the past several months, GHC has seen a surge of community involvement, and a great deal of new contributors. We now have 37 committers, with 14 added in 2013 alone — it’s an exciting time to help out!

Amongst those who have rolled up their sleeves and helped us recently:

Herbert Valerio Riedel has stepped up to the plate to help maintain http://ghc.haskell.org, all of our git repositories, and has become increasingly involved in library maintenance and development.

has stepped up to the plate to help maintain http://ghc.haskell.org, all of our git repositories, and has become increasingly involved in library maintenance and development. Takano Akio has submitted many great bug reports and patches recently, and has a keen eye for reproducing challenging or tricky bugs.

has submitted many great bug reports and patches recently, and has a keen eye for reproducing challenging or tricky bugs. Reid Barton has submitted some excellent patches to fix some awkward bugs, and helps us as we move towards Android cross compiler support.

has submitted some excellent patches to fix some awkward bugs, and helps us as we move towards Android cross compiler support. Kazu Yamamoto helped Andreas Voellmy in the improvements to the I/O manager, and has been extremely helpful in pointing out and reproducing bugs, and helping us find solutions.

helped Andreas Voellmy in the improvements to the I/O manager, and has been extremely helpful in pointing out and reproducing bugs, and helping us find solutions. Joachim Breitner implemented Coercible, but has also stepped up to merge patches, fix more bugs, and help set up some Continuous-Integration for GHC.

implemented Coercible, but has also stepped up to merge patches, fix more bugs, and help set up some Continuous-Integration for GHC. Carter Schonwald has been involved in talking with many who wish to get involved and inspiring them to get their hands dirty!

has been involved in talking with many who wish to get involved and inspiring them to get their hands dirty! Krzysztof Gogolewski has fixed many bugs, and like Takano, has helped reproduce and track down issues with fantastic test cases.

has fixed many bugs, and like Takano, has helped reproduce and track down issues with fantastic test cases. Jan Stolarek has helped improve the documentation of the low-level parts of the compiler, as well as implementing optimizations for us too.

has helped improve the documentation of the low-level parts of the compiler, as well as implementing optimizations for us too. Muhaimin Ahsan has been helping with infrastructure, writing patches, and generally offering help to us who are already busy.

As ever, there is a ton of stuff in the future for us to do. If you want something done — don’t wait, it might take a while. You should join us instead!

Links:

[Contr], https://github.com/ghc/ghc/graphs/contributors

[CTF-wiki], Closed type families with overlapping equations — http://ghc.haskell.org/trac/ghc/wiki/NewAxioms

[CTF-paper], Closed type families with overlapping equations, Richard Eisenberg, Dimitrios Vytiniotis, Simon Peyton Jones, Stephanie Weirich, POPL 2014 — http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/

[KD], Kinds without Data — http://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindsWithoutData

[NewTH1], Runtime codegen with typed Template Haskell — http://gmainland.blogspot.com/2013/05/type-safe-runtime-code-generation-with.html

[NewTH2], Major proposed Template Haskell revision — http://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges

[NTC], Newtype wrappers — http://ghc.haskell.org/trac/ghc/wiki/NewtypeWrappers

[PrimBool], New comparison primitives — http://ghc.haskell.org/trac/ghc/wiki/PrimBool

[ORF], Overloaded record fields — http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan

[PS], Pattern synonyms — http://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms

[Roles-wiki], Roles — http://ghc.haskell.org/trac/ghc/wiki/Roles

[Roles-paper], Generative Type Abstraction and Type-level Computation, Stephanie Wirich, Dimitrios Vytiniotis, Simon Peyton Jones, and Steve Zdancewic, POPL 2011 — http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/

[TA], Explicit type application — http://ghc.haskell.org/trac/ghc/wiki/ExplicitTypeApplication

3.2 Ajhc Haskell Compiler Report by: Kiwamu Okabe Participants: John Meacham, Hiroki MIZUNO, Hidekazu SEGAWA Status: experimental What is it? Ajhc is a Haskell compiler, and acronym for “A fork of jhc”. Jhc (http://repetae.net/computer/jhc/) converts Haskell code into pure C language code running with jhc’s runtime. And the runtime is written with 3000 lines (include comments) pure C code. It’s a magic! Ajhc’s mission is to keep contribution to jhc in the repository. Because the upstream author of jhc, John Meacham, can’t pull the contribution speedily. (I think he is too busy to do it.) We should feedback jhc any changes. Also Ajhc aims to provide the Metasepi project with a method to rewrite NetBSD kernel using Haskell. The method is called Snatch-driven development. Ajhc is, so to speak, an accelerator to develop jhc. What is new? Runtime: Ajhc now has thread-safe and reentrant runtime. The runtime supports pthread and custom thread that can shape forkOS API on tiny CPU with ChibiOS/RT. (https://github.com/metasepi/chibios-arafura) GC: New Erlang style GC. It means Ajhc’s Haskell context has own GC heap. Also new GC can run on tiny CPU such as Cortex-M3 with 64kB RAM. Document: We have translated Jhc User’s Manual into Japanese. The translating into the other language will be also easy, because the translaters are using gettext. (https://github.com/ajhc/ajhc/blob/arafura/po/ja.po) Demonstrations http://www.youtube.com/watch?v=n6cepTfnFoo The touchable cube application is written with Haskell and compiled by Ajhc. In the demo, the application is breaked by ndk-gdb debugger when running GC. You could watch the demo source code at https://github.com/ajhc/demo-android-ndk. http://www.youtube.com/watch?v=C9JsJXWyajQ The demo is running code that compiled with Ajhc on Cortex-M3 board, mbed. It’s a simple RSS reader for reddit.com, showing the RSS titles on Text LCD panel. You could watch the demo detail and source code at https://github.com/ajhc/demo-cortex-m3. http://www.youtube.com/watch?v=zkSy0ZroRIs The demo is running Haskell code without any OS. Also the clock exception handler is written with Haskell. Usage You can install Ajhc from Hackage. $ cabal install ajhc

$ ajhc --version

ajhc 0.8.0.9 (9c264872105597700e2ba403851cf3b

236cb1646)

compiled by ghc-7.6 on a x86_64 running linux

$ echo 'main = print "hoge"' > Hoge.hs

$ ajhc Hoge.hs

$ ./hs.out

"hoge"

Please read “Ajhc User’s Manual” to know more detail. (http://ajhc.metasepi.org/manual.html) Future plans Fix many BUGs. Try to rewrite (snatch) NetBSD kernel driver with Haskell. If we have luck, will port some library like array or vector from GHC world. After that, we are going to report back about developing Ajhc. License GPL2 or later. Contact Mailing list: http://groups.google.com/group/metasepi

Bug tracker: https://github.com/ajhc/ajhc/issues

Metasepi team: https://github.com/ajhc?tab=members Further reading Ajhc – Haskell everywhere: http://ajhc.metasepi.org/

jhc: http://repetae.net/computer/jhc/

Metasepi: Project http://metasepi.org/

Snatch-driven-development: http://www.slideshare.net/master_q/20131020-osc-tokyoajhc

UHC is the Utrecht Haskell Compiler, supporting almost all Haskell98 features and most of Haskell2010, plus experimental extensions. StatusCurrent work is on a strictness analyser (Augusto Pasalaqua) and incrementality of analysis via the Attribute Grammar system used to construct UHC (Jeroen Bransen). Background.UHC actually is a series of compilers of which the last is UHC, plus infrastructure for facilitating experimentation and extension. The distinguishing features for dealing with the complexity of the compiler and for experimentation are (1) its stepwise organisation as a series of increasingly more complex standalone compilers, the use of DSL and tools for its (2) aspectwise organisation (called Shuffle) and (3) tree-oriented programming (Attribute Grammars, by way of the Utrecht University Attribute Grammar (UUAG) system (→5.3.2). Further reading UHC Homepage: http://www.cs.uu.nl/wiki/UHC/WebHome

UHC Github repository: https://github.com/UU-ComputerScience/uhc

UHC Javascript backend: http://uu-computerscience.github.com/uhc-js/

Attribute grammar system: http://www.cs.uu.nl/wiki/HUT/AttributeGrammarSystem

3.4 Specific Platforms

The FreeBSD Haskell Team is a small group of contributors who maintain Haskell software on all actively supported versions of FreeBSD. The primarily supported implementation is the Glasgow Haskell Compiler together with Haskell Cabal, although one may also find Hugs and NHC98 in the ports tree. FreeBSD is a Tier-1 platform for GHC (on both i386 and amd64) starting from GHC 6.12.1, hence one can always download vanilla binary distributions for each recent release. We have a developer repository for Haskell ports that features around 486 ports of many popular Cabal packages. The updates committed to this repository are continuously integrated to the official ports tree on a regular basis. However, the FreeBSD Ports Collection already includes many popular and important Haskell software: GHC 7.6.3, Haskell Platform 2013.2.0.0, Gtk2Hs, wxHaskell, XMonad, Pandoc, Gitit, Yesod, Happstack, Snap, Agda, git-annex, and so on – all of them have been incorporated into the recent 9.2-RELEASE. In cooperation with fellow developers, Konstantin Belousov and Dimitry Andric, we have managed to restore the ability to build GHC on 32-bit 10.x FreeBSD systems, so now it is ready to be included in the upcoming 10.0-RELEASE. In addition, it turned out that this bug (in thread signal delivery) can also affect the building process for other platforms as well, which explains some of the strange build breakages our users might have experienced in the past. If you find yourself interested in helping us or simply want to use the latest versions of Haskell programs on FreeBSD, check out our page at the FreeBSD wiki (see below) where you can find all important pointers and information required for use, contact, or contribution. Further reading http://wiki.FreeBSD.org/Haskell

The Debian Haskell Group aims to provide an optimal Haskell experience to users of the Debian GNU/Linux distribution and derived distributions such as Ubuntu. We try to follow the Haskell Platform versions for the core package and package a wide range of other useful libraries and programs. At the time of writing, we maintain 628 source packages. A system of virtual package names and dependencies, based on the ABI hashes, guarantees that a system upgrade will leave all installed libraries usable. Most libraries are also optionally available with profiling enabled and the documentation packages register with the system-wide index. The recently released stable Debian release (“wheezy”) provides the Haskell Platform 2012.3.0.0 and GHC 7.4.1, while in Debian unstable, we provide the platform 2013.2.0.0 and GHC 7.6.3. Debian users benefit from the Haskell ecosystem on 13 architecture/kernel combinations, including the non-Linux-ports KFreeBSD and Hurd. Further reading http://wiki.debian.org/Haskell

The Fedora Haskell SIG works to provide good Haskell support in the Fedora Project Linux distribution. Fedora 19 shipped in July with ghc-7.4.2, haskell-platform-2012.4.0.0, and version updates to many other packages. New packages added since the previous release included cabal-rpm, and a bunch of libraries. Recently the Fedora Haskell Packaging Guidelines have been updated and revised which will make it easier for general package reviewers and give better control to packagers. Fedora 20 development is now at the Beta milestone with ghc-7.6.3, haskell-platform-2013.2.0.0, and numerous version updates: it is due to ship in December. New packages added during the Fedora 20 cycle include idris and various libraries. In Fedora 20 armv7 is now a Fedora primary architecture, and the inclusion of llvm-3.3 has caused problems since it is not properly supported by ghc-7.6.3. Work on packaging Yesod has slowly proceeded. At the time of writing we have around 250 Haskell source packages in Fedora. The cabal-rpm packaging tool has improved: it can now resolve C library and pkgconfig build dependencies, word-wrap descriptions, and yum install build dependencies. Work on Fedora 21 is also under way. I expect we will ship ghc-7.8 rather than waiting for Haskell Platform this time: it will be great to have shared library support beyond intel archs, and the many other enhancements. Static libraries will probably be moved into static subpackages If you want to help with Fedora Haskell packaging, please join our low-traffic mailing-list and the Freenode #fedora-haskell channel. You can also follow @fedorahaskell for irregular updates. Further reading Homepage: http://fedoraproject.org/wiki/SIGs/Haskell

Mailing-list: https://admin.fedoraproject.org/mailman/listinfo/haskell

Package list: https://admin.fedoraproject.org/pkgdb/users/packages/haskell-sig

Package changes: http://git.fedorahosted.org/cgit/haskell-sig.git/tree/packages/diffs/f19-f20.compare

4 Related Languages and Language Design

Agda is a dependently typed functional programming language (developed using Haskell). A central feature of Agda is inductive families, i.e., GADTs which can be indexed by values and not just types. The language also supports coinductive types, parameterized modules, and mixfix operators, and comes with an interactive interface—the type checker can assist you in the development of your code. A lot of work remains in order for Agda to become a full-fledged programming language (good libraries, mature compilers, documentation, etc.), but already in its current state it can provide lots of fun as a platform for experiments in dependently typed programming. Since the release of Agda 2.3.2 in November 2012 the following has happened in the Agda project and community: Ulf Norell gave a keynote speech at ICFP 2013 on dependently typed programming in Agda.

Agda has attracted new users, the traffic on the mailing list (and bug tracker) is increasing.

About 100 bugs of Agda 2.3.2 have been fixed; and small enhancements improve the usability.

Copatterns are being added to Agda as a new way to define record and coinductive values. Release of Agda 2.3.4 is planned to happen soon after the one of GHC 7.8. Release of Agda 2.3.4 is planned to happen soon after the one of GHC 7.8. Further reading The Agda Wiki: http://wiki.portal.chalmers.se/agda/

MiniAgda is a tiny dependently-typed programming language in the style of Agda (→4.1). It serves as a laboratory to test potential additions to the language and type system of Agda. MiniAgda’s termination checker is a fusion of sized types and size-change termination and supports coinduction. Bounded size quantification and destructor patterns for a more general handling of coinduction. Equality incorporates eta-expansion at record and singleton types. Function arguments can be declared as static; such arguments are discarded during equality checking and compilation. Recently, I have added pattern inductive families that need not store their indices even at type-checking time. MiniAgda is available as Haskell source code and compiles with GHC 6.12.x – 7.6.3. Further reading http://www2.tcs.ifi.lmu.de/~abel/miniagda/

4.3 Disciple Report by: Ben Lippmeier Status: experimental, active development Disciple Core is an explicitly typed language based on System-F2, intended as an intermediate representation for a compiler. In addition to the polymorphism of System-F2 it supports region, effect and closure typing. Evaluation order is left-to-right call-by-value by default, but explicit lazy evaluation is also supported. The language includes a capability system to track whether objects are mutable or constant, and to ensure that computations that perform visible side effects are not suspended with lazy evaluation. The Disciplined Disciple Compiler (DDC) is being rewritten to use the redesigned Disciple Core language. This new DDC is at a stage where it will parse and type-check core programs, and compile first-order functions over lists to executables via C or LLVM backends. There is also an interpreter that supports the full language. What is new? Over the last month we’ve been working on a new core language fragment, Disciple Core Flow, to support work on array fusion for Data Parallel Haskell (DPH). We’re writing a GHC plugin that translates GHC core programs to Disciple Core Flow, performs array fusion, and translates back. We’re using Disciple Core Flow instead of GHC Core directly because it has a simple (and working) external core format, which we use to test the fusion transform. Further reading http://disciple.ouroborus.net

4.4 Ermine Report by: Edward Kmett Participants: Dan Doel, Josh Cough, Elliot Stern, Stephen Compall, Runar Oli Bjarnason, Paul Chiusano Status: actively developed, experimental Ermine is a Haskell-like programming language, extended with rank-N types, kind and row polymorphism that runs on the JVM designed at McGraw Hill Financial. The language currently has two implementations, a legacy implementation that was written in Scala, and a newer, more extensible, implementation that is actively being developed in Haskell. The Scala implementation is designed more or less as a straight interpreter, while the Haskell version is designed to be able to compile down to a smaller, relatively portable core. Neither backend generates Java bytecode directly to avoid leaking “Permgen” space. In July, we were able to obtain corporate approval to open source the existing Scala-based compiler and the nascent Haskell implementation. The Scala version of the language is being actively used to generate a number of financial reports within the S&P Capital IQ web platform. An introduction to Ermine has been given at Boston Haskell and at CUFP 2013. Stephen Compall has been putting together a documentation project. Further reading Ermine Github: http://github.com/ermine-language

Boston Haskell Presentation: http://www.youtube.com/watch?v=QCvXlOCBe5A

A Taste of Ermine: https://launchpad.net/ermine-user-guide

CUFP Slides: http://tinyurl.com/qem8phk

5 Haskell and …

5.1 Haskell and Parallelism

Eden extends Haskell with a small set of syntactic constructs for explicit process specification and creation. While providing enough control to implement parallel algorithms efficiently, it frees the programmer from the tedious task of managing low-level details by introducing automatic communication (via head-strict lazy lists), synchronization, and process handling. Eden’s primitive constructs are process abstractions and process instantiations. The Eden logo consists of four λ turned in such a way that they form the Eden instantiation operator (#). Higher-level coordination is achieved by defining skeletons, ranging from a simple parallel map to sophisticated master-worker schemes. They have been used to parallelize a set of non-trivial programs. Eden’s interface supports a simple definition of arbitrary communication topologies using Remote Data. A PA-monad enables the eager execution of user defined sequences of Parallel Actions in Eden. Survey and standard reference Rita Loogen, Yolanda Ortega-Mallén, and Ricardo Peña: Parallel Functional Programming in Eden, Journal of Functional Programming 15(3), 2005, pages 431–475. Tutorial Rita Loogen: Eden - Parallel Functional Programming in Haskell, in: V. Zsok, Z. Horvath, and R. Plasmeijer (Eds.): CEFP 2011, Springer LNCS 7241, 2012, pp. 142-206.

(see also: http://www.mathematik.uni-marburg.de/~eden/?content=cefp) Implementation Eden is implemented by modifications to the Glasgow-Haskell Compiler (extending its runtime system to use multiple communicating instances). Apart from MPI or PVM in cluster environments, Eden supports a shared memory mode on multicore platforms, which uses multiple independent heaps but does not depend on any middleware. Building on this runtime support, the Haskell package edenmodules defines the language, and edenskels provides a library of parallel skeletons. A new version based on GHC-7.8.1 (including binary packages and prepared source bundles) will be released as soon as its baseline GHC is released (expected release date: November 25). The new version fixes a number of issues related to error shut-down and recovery, and features extended support for serialising Haskell data structures. The previous stable release with binary packages and bundles was based on GHC 7.4.2, and is still available on the Eden web pages. The source code repository for Eden releases is http://james.mathematik.uni-marburg.de:8080/gitweb, the Eden libraries (Haskell-level) are also available via Hackage. Tools and libraries The Eden trace viewer tool EdenTV provides a visualisation of Eden program runs on various levels. Activity profiles are produced for processing elements (machines), Eden processes and threads. In addition message transfer can be shown between processes and machines. EdenTV is written in Haskell and is freely available on the Eden web pages and on hackage. The Eden skeleton library is under constant development. Currently it contains various skeletons for parallel maps, workpools, divide-and-conquer, topologies and many more. Take a look on the Eden pages. Recent and Forthcoming Publications Mischa Dieterle, Thomas Horstmeyer, Jost Berthold, Rita Loogen: Iterating Skeletons — Structured Parallelism by Composition , Selected Papers of the Symposium on the Implementation and Application of Functional Languages (IFL 2012), LNCS 8241, Springer 2013, pp. 18-36.

, Selected Papers of the Symposium on the Implementation and Application of Functional Languages (IFL 2012), LNCS 8241, Springer 2013, pp. 18-36. M. KH. Aswad, P. W. Trinder, A. D. Al-Zain, G. J. Michaelson, J. Berthold: Comparing Low-Pain and No-Pain Multicore Haskells , revised and extended version of TFP 2009 paper, in Special Issue of Higher-Order Symbol Computation (HOSC), to appear.

, revised and extended version of TFP 2009 paper, in Special Issue of Higher-Order Symbol Computation (HOSC), to appear. Thomas Horstmeyer and Rita Loogen: Graph-Based Communication in Eden , revised and extended version of TFP 2009 paper, in Special Issue of Higher-Order Symbol Computation (HOSC), to appear.

, revised and extended version of TFP 2009 paper, in Special Issue of Higher-Order Symbol Computation (HOSC), to appear. Oleg Lobachev, Michael Guthe, Rita Loogen: Estimating parallel performance , Journal of Parallel and Distributed Computing, Vol 73, No. 6, June 2013, pp. 876 - 887.

, Journal of Parallel and Distributed Computing, Vol 73, No. 6, June 2013, pp. 876 - 887. Jost Berthold: Run-time supported Haskell Serialisation - an API. Talk at the Haskell Implementors’ Workshop, Boston, September 2013. Further reading http://www.mathematik.uni-marburg.de/~eden

5.1.2 Parallel GHC project Report by: Duncan Coutts Participants: Duncan Coutts, Andres Löh, Mikolaj Konarski, Edsko de Vries Status: active Microsoft Research funded a 2-year project, which is now coming to an end, to promote the real-world use of parallel Haskell. The project involved industrial partners working on their own tasks using parallel Haskell, and consulting and engineering support from Well-Typed (→8.1). The overall goal has been to demonstrate successful serious use of parallel Haskell, and along the way to apply engineering effort to any problems with the tools that the organisations might run into. In addition we have put significant engineering work into a new implementation of Cloud Haskell. The participating organisations are working on a diverse set of complex real world problems: Dragonfly (New Zealand): Hierarchical Bayesian Modeling

Los Alamos National Laboratory (USA): high performance Monte Carlo algorithms to model the flow of radiation and other physical phenomena

IIJ Innovation Institute Inc. (Japan): network servers handling a massive number of concurrent connections

Telefonica I+D: processing large graphs representing social networks As the project winds down, we will be publishing more details about the outcomes of these projects. On the engineering side, the two main areas of focus in the project recently have been ThreadScope and Cloud Haskell. ThreadScope.The latest release of ThreadScope (version 0.2.2) provides detailed statistics about heap and GC behaviour. It is much like the output that can be obtained by running your program with +RTS -s but presented in a more friendly way and with the ability to see the same statistics for any period within the program, not just the entire program run. This work could be extended to show graphs of the heap size over time. Compared to GHC’s traditional heap profiling this does not require recompiling in profiling mode and is very low overhead, but what is lost is the detailed breakdown of the heap by type, cost centre or retainer. In addition there is a new feature to emit phase markers from user code and have these visualised in the ThreadScope timeline window. These new features rely on the development version of GHC, and so will become generally available with GHC-7.8. Finally, there is an alpha release of an ambitious new feature to integrate data from Linux’s “perf” system into ThreadScope. The Linux “perf” system lets us see events in the OS such as system calls and other internal kernel trace points, and also to collect detailed CPU performance counters. Our work has focused on capturing and transforming this data source, and integrating it with the existing RTS event tracing system which we believe will enable many useful new visualisations. Our initial new visualisation in ThreadScope lets us see when system calls are occurring. We hope that this and other future work in this area will help developers who are trying to optimise the performance of applications like network servers. Cloud Haskell.For about the last year we have been working on a new implementation of Cloud Haskell. This is the same idea for concurrent distributed programming in Haskell that Simon Peyton Jones has been telling everyone about, but it’s a new implementation designed to be robust and flexible. The summary about the new implementation is that it exists, it works, it’s on hackage, and we think it is now ready for serious experiments. Compared to the previous prototype: it is much faster;

it can run on multiple kinds of network;

has backends to support different environments (like cluster or cloud);

has a new system for dealing with node disconnect and reconnect;

has a more precisely defined semantics;

supports composable, polymorphic serialisable closures;

and internally the code is better structured and easier to work with. By the time you read this, we will have also released a backend for the Windows Azure cloud platform. Backends for other environments should be relatively straightforward to develop. Further details including papers, videos and blog posts are on the Cloud Haskell homepage. Further reading Parallel GHC project homepage: http://www.haskell.org/haskellwiki/Parallel_GHC_Project

Cloud Haskell homepage: http://www.haskell.org/haskellwiki/Cloud_Haskell

ThreadScope homepage: http://www.haskell.org/haskellwiki/ThreadScope

5.1.3 speculation Report by: Edward Kmett Participants: Jake McArthur Status: stable This package provides speculative function application and speculative folds based on Prakash Prabhu, G. Ramalingam, and Kapil Vaswani, “Safe Programmable Speculative Parallelism”, In the proceedings of Programming Language Design and Implementation (PLDI) Vol 45, Issue 6 (June 2010) pp 50-61. Unlike the original paper, we can take advantage of immutability and the spark queue in Haskell to ensure we never worsen the asymptotics of a single-threaded algorithm. Speculative STM transactions take the place of the transactional rollback machinery from the paper. Unlike the original paper, we can take advantage of immutability and the spark queue in Haskell to ensure we never worsen the asymptotics of a single-threaded algorithm. Speculative STM transactions take the place of the transactional rollback machinery from the paper. Further reading http://hackage.haskell.org/package/speculation

http://research.microsoft.com/pubs/118795/pldi026-vaswani.pdf

5.2 Haskell and the Web

5.2.1 WAI Report by: Michael Snoyman Participants: Greg Weber Status: stable The Web Application Interface (WAI) is an interface between Haskell web applications and Haskell web servers. By targeting the WAI, a web framework or web application gets access to multiple deployment platforms. Platforms in use include CGI, the Warp web server, and desktop webkit. WAI has mostly been stable since the last HCAR, with the exception of a newly added field to represent the request body length. This avoids repeatedly doing a costly integer parse, and correctly handling the case of chunked bodies at the type level. WAI has also been updated to allow the newest version of the conduit (→7.1.1) package. WAI is also a platform for re-using code between web applications and web frameworks through WAI middleware and WAI applications. WAI middleware can inspect and transform a request, for example by automatically gzipping a response or logging a request. The Yesod (→5.2.6) web framework provides the ability to embed arbitrary WAI applications as subsites, making them a part of a larger web application. By targeting WAI, every web framework can share WAI code instead of wasting effort re-implementing the same functionality. There are also some new web frameworks that take a completely different approach to web development that use WAI, such as webwire (FRP) and dingo (GUI). The Scotty web framework also continues to be developed, and provides a lighter-weight alternative to Yesod. Other frameworks- whether existing or newcomers- are welcome to take advantage of the existing WAI architecture to focus on the more innovative features of web development. WAI applications can send a response themselves. For example, wai-app-static is used by Yesod to serve static files. However, one does not need to use a web framework, but can simply build a web application using the WAI interface alone. The Hoogle web service targets WAI directly. The WAI standard has proven itself capable for different users and there are no outstanding plans for changes or improvements. Further reading http://www.yesodweb.com/book/wai

5.2.2 Warp Report by: Michael Snoyman Warp is a high performance, easy to deploy HTTP server backend for WAI (→5.2.1). Since the last HCAR, Warp has switched from enumerators to conduits (→7.1.1), added SSL support, and websockets integration. Due to the combined use of ByteStrings, blaze-builder, conduit, and GHC’s improved I/O manager, WAI+Warp has consistently proven to be Haskell’s most performant web deployment option. Warp is actively used to serve up most of the users of WAI (and Yesod). “Warp: A Haskell Web Server” by Michael Snoyman was published in the May/June 2011 issue of IEEE Internet Computing: Issue page: http://www.computer.org/portal/web/csdl/abs/mags/ic/2011/03/mic201103toc.htm

PDF: http://steve.vinoski.net/pdf/IC-Warp_a_Haskell_Web_Server.pdf

5.2.3 Holumbus Search Engine Framework Report by: Uwe Schmidt Participants: Timo B. Kranz, Sebastian Gauck, Stefan Schmidt Status: first release Description The Holumbus framework consists of a set of modules and tools for creating fast, flexible, and highly customizable search engines with Haskell. The framework consists of two main parts. The first part is the indexer for extracting the data of a given type of documents, e.g., documents of a web site, and store it in an appropriate index. The second part is the search engine for querying the index. An instance of the Holumbus framework is the Haskell API search engine Hayoo! (http://holumbus.fh-wedel.de/hayoo/). The framework supports distributed computations for building indexes and searching indexes. This is done with a MapReduce like framework. The MapReduce framework is independent of the index- and search-components, so it can be used to develop distributed systems with Haskell. The framework is now separated into four packages, all available on Hackage. The Holumbus Search Engine

The Holumbus Distribution Library

The Holumbus Storage System

The Holumbus MapReduce Framework The search engine package includes the indexer and search modules, the MapReduce package bundles the distributed MapReduce system. This is based on two other packages, which may be useful for their on: The Distributed Library with a message passing communication layer and a distributed storage system. Features Highly configurable crawler module for flexible indexing of structured data

Customizable index structure for an effective search

find as you type search

search Suggestions

Fuzzy queries

Customizable result ranking

Index structure designed for distributed search

Git repository containing the current development version of all packages under https://github.com/fortytools/holumbus

Distributed building of search indexes Current Work Currently there are activities to optimize the index structures of the framework. In the past there have been problems with the space requirements during indexing. The data structures and evaluation strategies have been optimized to prevent space leaks. A second index structure working with cryptographic keys for document identifiers is under construction. This will further simplify partial indexing and merging of indexes. There is a small project extracting the sources of the data structure used for the index to build a separate package. The search tree used in Holumbus is a space optimised version of a radix tree, which enables fast prefix and fuzzy search. The second project, a specialized search engine for the FH-Wedel web site, has been finished http://w3w.fh-wedel.de/. The new aspect in this application is a specialized free text search for appointments, deadlines, announcements, meetings and other dates. The Hayoo! and the FH-Wedel search engine have been adopted to run on top of the Snap framework (→5.2.7). Further reading The Holumbus web page (http://holumbus.fh-wedel.de/) includes downloads, Git web interface, current status, requirements, and documentation. Timo Kranz’s master thesis describing the Holumbus index structure and the search engine is available at http://holumbus.fh-wedel.de/branches/develop/doc/thesis-searching.pdf. Sebastian Gauck’s thesis dealing with the crawler component is available at http://holumbus.fh-wedel.de/src/doc/thesis-indexing.pdf The thesis of Stefan Schmidt describing the Holumbus MapReduce is available via http://holumbus.fh-wedel.de/src/doc/thesis-mapreduce.pdf.

5.2.4 Happstack Report by: Jeremy Shaw Happstack is a fast, modern framework for creating web applications. Happstack is well suited for MVC and RESTful development practices. We aim to leverage the unique characteristics of Haskell to create a highly-scalable, robust, and expressive web framework. Happstack pioneered type-safe Haskell web programming, with the creation of technologies including web-routes (type-safe URLS) and acid-state (native Haskell database system). We also extended the concepts behind formlets, a type-safe form generation and processing library, to allow the separation of the presentation and validation layers. Some of Happstack’s unique advantages include: a large collection of flexible, modular, and well documented libraries which allow the developer to choose the solution that best fits their needs for databases, templating, routing, etc.

the most flexible and powerful system for defining type-safe URLs.

a type-safe form generation and validation library which allows the separation of validation and presentation without sacrificing type-safety

a powerful, compile-time HTML templating system, which allows the use of XML syntax A recent addition to the Happstack family is the happstack-foundation library. It combines what we believe to be the best choices into a nicely integrated solution. happstack-foundation uses: happstack-server for low-level HTTP functionality

acid-state for type-safe database functionality

web-routes for type-safe URL routing

reform for type-safe form generation and processing

HSP for compile-time, XML-based HTML templates

JMacro for compile-time Javascript generation and syntax checking Future plans Happstack is the oldest, actively developed Haskell web framework. We are continually studying and applying new ideas to keep Happstack fresh. By the time the next release is complete, we expect very little of the original code will remain. If you have not looked at Happstack in a while, we encourage you to come take a fresh look at what we have done. Some of the projects we are currently working on include: a fast pipes-based HTTP and websockets backend with a high level of evidence for correctness

a dynamic plugin loading system

a more expressive system for weakly typed URL routing combinators

a new system for processing form data which allows fine grained enforcement of RAM and disk quotas and avoids the use of temporary files

a major refactoring of HSP (fewer packages, migration to Text/Builder, a QuasiQuoter, and more). One focus of Happstack development is to create independent libraries that can be easily reused. For example, the core web-routes and reform libraries are in no way Happstack specific and can be used with other Haskell web frameworks. Additionally, libraries that used to be bundled with Happstack, such as IxSet, SafeCopy, and acid-state, are now independent libraries. The new backend will also be available as an independent library. When possible, we prefer to contribute to existing libraries rather than reinvent the wheel. For example, our preferred templating library, HSP, was created by and is still maintained by Niklas Broberg. However, a significant portion of HSP development in the recent years has been fueled by the Happstack team. We are also working directly with the Fay team to bring an improved type-safety to client-side web programming. In addition to the new happstack-fay integration library, we are also contributing directly to Fay itself. For more information check out the happstack.com website — especially the “Happstack Philosophy” and “Happstack 8 Roadmap”. Further reading http://www.happstack.com/

http://www.happstack.com/docs/crashcourse/index.html

Mighttpd (called mighty) version 2 is a simple but practical Web server in Haskell. It is now working on Mew.org serving static files, CGI (mailman and contents search) and reverse proxy for back-end Yesod applications. Mighttpd is based on Warp providing performance on par with nginx . You can use the mightyctl command to reload configuration files dynamically and shutdown Mighttpd gracefully. You can install Mighttpd 2 (mighttpd2) from HackageDB. Michael Snoyman and I are now working on WAI 2. So far, we improved the performance of Warp much. Mighty version 3 will be based on this new Warp and also provides much faster logger than the fast-logger package. Further reading http://www.mew.org/~kazu/proj/mighttpd/en/

http://www.iij.ad.jp/en/company/development/tech/mighttpd/

http://aosabook.org/en/posa/warp.html

5.2.6 Yesod Report by: Michael Snoyman Participants: Greg Weber, Luite Stegeman, Felipe Lessa Status: stable Yesod is a traditional MVC RESTful framework. By applying Haskell’s strengths to this paradigm, Yesod helps users create highly scalable web applications. Performance scalablity comes from the amazing GHC compiler and runtime. GHC provides fast code and built-in evented asynchronous IO. But Yesod is even more focused on scalable development. The key to achieving this is applying Haskell’s type-safety to an otherwise traditional MVC REST web framework. Of course type-safety guarantees against typos or the wrong type in a function. But Yesod cranks this up a notch to guarantee common web application errors won’t occur. declarative routing with type-safe urls — say goodbye to broken links

no XSS attacks — form submissions are automatically sanitized

database safety through the Persistent library (→7.6.2) — no SQL injection and queries are always valid

valid template variables with proper template insertion — variables are known at compile time and treated differently according to their type using the shakesperean templating system. When type safety conflicts with programmer productivity, Yesod is not afraid to use Haskell’s most advanced features of Template Haskell and quasi-quoting to provide easier development for its users. In particular, these are used for declarative routing, declarative schemas, and compile-time templates. MVC stands for model-view-controller. The preferred library for models is Persistent (→7.6.2). Views can be handled by the Shakespeare family of compile-time template languages. This includes Hamlet, which takes the tedium out of HTML. Both of these libraries are optional, and you can use any Haskell alternative. Controllers are invoked through declarative routing and can return different representations of a resource (html, json, etc). Yesod is broken up into many smaller projects and leverages Wai (→5.2.1) to communicate with the server. This means that many of the powerful features of Yesod can be used in different web development stacks that use WAI such as Scotty. The new 1.2 release of Yesod, introduces a number of simplifications, especially to the subsite handling. Most applications should be able to upgrade easily. Some of the notable features are: Much more powerful multi-representation support via the selectRep/provideRep API.

More efficient session handling.

All Handler functions live in a typeclass, providing you with auto-lifting.

Type-based caching of responses via the cached function.

More sensible subsite handling, switch to HandlerT/WidgetT transformers.

Simplified dispatch system, including a lighter-weight Yesod.

Simplified streaming data mechanism, for both database and non-database responses.

Completely overhauled yesod-test, making it easier to use and providing cleaner integration with hspec.

yesod-auth’s email plugin now supports logging in via username in addition to email address.

Refactored persistent module structure for clarity and ease-of-use.

Easy asset combining for static javascript and css files

Faster shakespeare template reloading and support for TypeScript templates. Since the 1.0 release, Yesod has maintained a high level of API stability, and we intend to continue this tradition. The 1.2 release introduces a lot of potential code breakage, but most of the required updates should be very straightforward. Future directions for Yesod are now largely driven by community input and patches. We’ve been making progress on the goal of easier client-side interaction, and have high-level interaction with languages like Fay, TypeScript, and CoffeScript. The Yesod site (http://www.yesodweb.com/) is a great place for information. It has code examples, screencasts, the Yesod blog and — most importantly — a book on Yesod. To see an example site with source code available, you can view Haskellers (→1.2) source code: (https://github.com/snoyberg/haskellers). Further reading http://www.yesodweb.com/

The Snap Framework is a web application framework built from the ground up for speed, reliability, and ease of use. The project’s goal is to be a cohesive high-level platform for web development that leverages the power and expressiveness of Haskell to make building websites quick and easy. In the six months since the last HCAR Snap has had two major new releases. In 0.12 we added features enabling more efficient and granular reloading of snap applications, allowing a much faster development cycle. The 0.13 release centered around a new high-level API for Heist’s compiled splices. The new API greatly simplifies compiled Heist. In addition, we introduced a new syntax that makes defining splices more convenient. Our next major milestone on the roadmap is to put the finishing touches on our complete rewrite of the Snap web server using io-streams . If you would like to contribute, stop by the #snapframework IRC channel on Freenode to keep up with the latest activity. Further reading 0.12 release announcement: http://snapframework.com/blog/2013/05/15/snap-0.12-released

0.13 release announcement: http://snapframework.com/blog/2013/09/09/snap-0.13-released

A blog post demonstrating the faster reloading capability: http://devblog.soostone.com/posts/2013-06-17-snap-template-reloading.html

Snaplet Directory: http://snapframework.com/snaplets

http://snapframework.com

5.2.8 Sunroof Report by: Andy Gill Participants: Jan Bracker Status: active Sunroof is a Domain Specific Language (DSL) for generating JavaScript. It is built on top of the JS-monad, which, like the Haskell IO-monad, allows read and write access to external resources, but specifically JavaScript resources. As such, Sunroof is primarily a feature-rich foreign function API to the browser’s JavaScript engine, and all the browser-specific functionality, like HTML-based rendering, event handling, and drawing to the HTML5 canvas. Furthermore, Sunroof offers two threading models for building on top of JavaScript, atomic and blocking threads. This allows full access to JavaScript APIs, but using Haskell concurrency abstractions, like MVars and Channels. In combination with the push mechanism Kansas-Comet, Sunroof offers a great platform to build interactive web applications, giving the ability to interleave Haskell and JavaScript computations with each other as needed. It has successfully been used to write smaller applications. These applications range from 2D rendering using the HTML5 canvas element, over small GUIs, up to executing the QuickCheck tests of Sunroof and displaying the results in a neat fashion. The development has been active over the past 6 months and there is a drafted paper submitted to TFP 2013. Further reading Homepage: http://www.ittc.ku.edu/csdl/fpg/software/sunroof.html

Tutorial: https://github.com/ku-fpg/sunroof-compiler/wiki/Tutorial

Main Repository: https://github.com/ku-fpg/sunroof-compiler

5.2.9 MFlow Report by: Alberto Gomez Corona Status: active development MFlow is an innovative Web framework of the kind of other functional, stateful frameworks like WASH, Seaside, Ocsigen or Racket. MFlow does not use continuation passing, but a backtracking monad that carries out the synchronization of browser request and server process execution state. This monad is on top of another “Workflow” monad that adds effects for logging and recovery of process/session state. Logging/recovery was the continuation mechanism used by WASH, but unlike WASH, MFlow processes don’t die and recover on each request, but stay in memory and synchronize using backtracking. Both effects are managed by an application server that dispatches each request to the appropriate server process. In case of timeout, the process is restarted using the state recovering mechanism. The logs generated are very small, so MFlow solves the problems of fat serializations associated with stateful frameworks. Like the continuation-based frameworks, MFlow inverts back the inversion of control, so programming multipage web applications is simple and natural. At the same time MFlow is RESTful. Not only the URL use the REST style, but also any GET page in the flow can be pointed to with a REST URL. That is unique for a stateful WF. Additionally, besides applicative formlets, it also implements monadic formlets by means of a page monad that permits to dynamically change the page content and input fields depending on the user input. This is called “page flows”. widgets can have their own flow within a page. If desired, thanks to the runtime templates, the HTML layout and content generated can be modified at runtime. using a web-based WYSIWYG tool included, so the separation of layout and logic is beyond any other web framework. Other features are widget autorefreshing via implicit AJAX, container widgets (widgets that contain widgets), integration with Persistent, integration with AWS, JQuery integration, WAI integration, blaze-html integration, push using long polling and complete execution traces for errors (thanks to the backtracking monad). MFlow hides the heterogeneous elements of a web application and expose a clear, modular, type safe DSL of applicative and monadic combinators that pack the client side javascript, the HTML rendering, the CSS and the server code to create from multipage applcations to single page, dynamic interfaces. It may be considered the continuation of the great WASH framework. Further reading There is a site, made using MFlow, which includes demos at: http://mflowdemo.herokuapp.com

5.3 Haskell and Compiler Writing

5.3.1 MateVM Report by: Bernhard Urban Participants: Harald Steinlechner Status: active development MateVM is a method-based Java Just-In-Time Compiler. That is, it compiles a method to native code on demand (i.e. on the first invocation of a method). We use existing libraries: hs-java for proccessing Java Classfiles according to The Java Virtual Machine Specification. harpy enables runtime code generation for i686 machines in Haskell, in a domain specific language style. We think that Haskell is suitable for compiler challenges, as already many times proven. However, we have to jump between “Haskell world” and “native code world”, due to the requirements of a Just-In-Time Compiler. This poses some special challenges when it comes to signal handling and other interesing rather low level operations. Not immediately visible, the task turns out to be well suited for Haskell although we experienced some tensions with signal handling and GHCi. We are looking forward to sharing our experience on this. We think that Haskell is suitable for compiler challenges, as already many times proven. However, we have to jump between “Haskell world” and “native code world”, due to the requirements of a Just-In-Time Compiler. This poses some special challenges when it comes to signal handling and other interesing rather low level operations. Not immediately visible, the task turns out to be well suited for Haskell although we experienced some tensions with signal handling and GHCi. We are looking forward to sharing our experience on this. In the current state we are able to execute simple Java programs. The compiler eliminates the JavaVM stack via abstract interpretation, does a liveness analysis, linear scan register allocation and finally code emission. The architecture enables easy addition of further optimization passes on an intermediate representation. Future plans are, to add an interpreter to gather profile information for the compiler and also do more aggressive optimizations (e.g. method inlining or stack allocation) , using the interpreter as fallback path via deoptimization if a assumption is violated. Apart from that, many features are missing for a full JavaVM, most noteable are the concept of Classloaders, Floating Point or Threads. We would like to use GNU Classpath as base library some day. Other hot topics are Hoopl and Garbage Collection. If you are interested in this project, do not hesitate to join us on IRC ( #MateVM @ OFTC ) or contact us on Github. Further reading https://github.com/MateVM

http://docs.oracle.com/javase/specs/jvms/se7/html/

http://hackage.haskell.org/package/hs-java

http://hackage.haskell.org/package/harpy

http://www.gnu.org/software/classpath/

http://hackage.haskell.org/package/hoopl-3.8.7.4

http://en.wikipedia.org/wiki/Club-Mate

UUAG is the Utrecht University Attribute Grammar system. It is a preprocessor for Haskell that makes it easy to write catamorphisms, i.e., functions that do to any data type what foldr does to lists. Tree walks are defined using the intuitive concepts of inherited and synthesized attributes, while keeping the full expressive power of Haskell. The generated tree walks are efficient in both space and time. An AG program is a collection of rules, which are pure Haskell functions between attributes. Idiomatic tree computations are neatly expressed in terms of copy, default, and collection rules. Attributes themselves can masquerade as subtrees and be analyzed accordingly (higher-order attribute). The order in which to visit the tree is derived automatically from the attribute computations. The tree walk is a single traversal from the perspective of the programmer. Nonterminals (data types), productions (data constructors), attributes, and rules for attributes can be specified separately, and are woven and ordered automatically. These aspect-oriented programming features make AGs convenient to use in large projects. The system is in use by a variety of large and small projects, such as the Utrecht Haskell Compiler UHC (→3.3), the editor Proxima for structured documents (http://www.haskell.org/communities/05-2010/html/report.html#sect6.4.5), the Helium compiler (http://www.haskell.org/communities/05-2009/html/report.html#sect2.3), the Generic Haskell compiler, UUAG itself, and many master student projects. The current version is 0.9.50 (August 2013), is extensively tested, and is available on Hackage. There is also a Cabal plugin for easy use of AG files in Haskell projects. Some of the recent changes to the UUAG system are: OCaml and Clean support. We have added OCaml and Clean code generation such that UUAG can also be used in OCaml projects and in Clean projects. We are currently working on the following enhancements: Evaluation scheduling and fixed point computation. We are running a project to improve the scheduling algorithms in combination with fixed point computations. The currently implemented algorithms for scheduling AG computations do not fully satisfy our needs; the code we write goes beyond the class of OAGs, but the algorithm by Kennedy and Warren (1976) results in an undesired increase of generated code due to non-linear evaluation orders. However, because we know that our code belongs to the class of linear orderable AGs, we would like to find and algorithm that can find this linear order, and thus lies in between the two existing approaches. Fixed point computations and ordered AG computations do not easily mix. In some cases however we would like to include fixed point computations inside an ordered AG, so the second aim of this project is to introduce way of letting the user specify such computations, and evaluate these in the right way. Incremental evaluation. We are currently also running a Ph.D. project that investigates incremental evaluation of AGs. In this ongoing work we hope to improve the UUAG compiler by adding support for incremental evaluation, for example by statically generating different evaluation orders based on changes in the input. Further reading http://www.cs.uu.nl/wiki/bin/view/HUT/AttributeGrammarSystem

http://hackage.haskell.org/package/uuagc

LQPL (Linear Quantum Programming Language) is a functional quantum programming language inspired by Peter Selinger’s paper “Towards a Quantum Programming Language”. The LQPL system consists of a compiler, a GUI based front end and an emulator. LQPL incorporates a simple module / include system (more like C’s include than Haskell’s import), predefined unitary transforms, quantum control and classical control, algebraic data types, and operations on purely classical data. Starting with the 0.9 series, LQPL is now split into separate components: The compiler (Haskell) — available at the command line and via a TCP/IP interface;

The emulator (which emulates a virtual quantum machine) (Haskell) — available as a server via a TCP/IP interface;

The front end (JRuby/Swing) — which connects to both the compiler and the emulator via TCP/IP. Version 0.9.1 was a bugfix release. A screenshot of the interface (showing a probabilistic list) is included below. Quantum programming allows us to provide a fair coin toss: qdata Coin = {Heads | Tails}

toss ::( ; c:Coin) =

{ q = |0>; Had q;

measure q of |0> => {c = Heads}

|1> => {c = Tails}

}

This allows programming of probabilistic algorithms, such as leader election. This allows programming of probabilistic algorithms, such as leader election. The next major items on the road map are: Change the TCP/IP data format to something less verbose;

Implementing a translation of the virtual machine code into quantum circuits. Further reading Documentation and executable downloads may be found at http://pll.cpsc.ucalgary.ca/lqpl/index.html. The source code, along with a wiki and bug tracker, is available at https://bitbucket.org/BrettGilesUofC/lqpl.

5.3.4 free — Free Monads Report by: Edward Kmett Participants: Gabriel Gonzalez, Aristid Breitkreuz, Nickolay Kudasov, Ben Gamari, Matvey Aksenov, Mihaly Barasz, Twan van Laarhoven Status: actively developed This package provides common definitions for working with free monads and free applicatives. These are very useful when it comes to defining EDSLs. This package also supports cofree comonads, which are useful for tracking attributes through a syntax tree. Recently support was added for the free completely-iterative monad of a monad as well. This can be used as part of a scheme to deamortize calculations in the |ST s| monad. Further reading http://hackage.haskell.org/package/free

http://www.haskellforall.com/2012/06/you-could-have-invented-free-monads.html

http://www.iai.uni-bonn.de/~jv/mpc08.pdf

http://comonad.com/reader/2011/free-monads-for-less/

http://comonad.com/reader/2011/free-monads-for-less-2/

http://comonad.com/reader/2011/free-monads-for-less-3/

http://paolocapriotti.com/assets/applicative.pdf

http://skillsmatter.com/podcast/scala/monads-for-free

http://comonad.com/reader/2009/incremental-folds/

http://www.ioc.ee/~tarmo/tday-veskisilla/uustalu-slides.pdf

https://www.fpcomplete.com/user/edwardk/oblivious/deamortized-st

5.3.5 bound — Making De Bruijn Succ Less Report by: Edward Kmett Participants: Nicolas Pouillard, Jean-Philippe Bernardy, Andrea Vezzosi, Gabor Greif, Matvey B. Aksenov Status: actively developed This library provides convenient combinators for working with “locally-nameless” terms. These can be useful when writing a type checker, evaluator, parser, or pretty printer for terms that contain binders like forall or lambda, as they ease the task of avoiding variable capture and testing for alpha-equivalence. Notably, it uses a representation based on type-safe generalized De Bruijn indices that lets you naturally make your expression type into a |Monad| that permits capture-avoiding substitution, and the use of |Foldable|’s |toList| and |Traversable|’s |traverse| to find free variables. This makes it much easier to manipulate your syntax tree with tools you already know how to use, while still safely avoiding issues with name capture. The generalized De Bruijn encoding permits asymptotic improvement in the running time of many calculations, enabling simultaneous substitution of everything within a complex binder, O(1) lifting, and avoiding paying for the traversal of lifted trees, but the complexity of the encoding is hidden behind a monad transformer that provides you with variable capture. Further reading http://fpcomplete.com/user/edwardk/bound

http://hackage.haskell.org/package/bound

http://www.slideshare.net/ekmett/bound-making-de-bruijn-succ-less

6 Development Tools

6.1 Environments

6.1.1 Haskell IDE From FP Complete Report by: Michael Snoyman Status: available, stable This past September, FP Complete officially launched the world’s first commercial Haskell IDE and Development Platform, FP Haskell Center. The IDE includes a Haskell compiler and a continually updated set of vetted, tested and supported libraries and code templates. There is no need to run Cabal or other installers to use it. Key features include: Continuous compile with real-time type information and error messaging

Haddocks documentation and Hoogle search

Syntax highlighting

Git/GitHub integration

Team management tools

Remote version control

An integrated web deployment platform

Subscriptions include continuous refresh releases on new features, updates, bug fixes and free community support FP Complete started this project by researching existing solutions to determine what to include in the IDE. They looked at Haskell editor extensions, especially Vim and Emacs, and at existing Haskell IDEs like Eclipse FP, Leksah, and Yi as well as looking at what supporting functionality was readily available: the GHC API, Hoogle, Haddock, Hlint, and many others. From there, FP Complete focused on creating an intuitive interface to make programing within the IDE a seamless experience. To ensure FP Haskell Center is meeting the demands of the Haskell community, FP complete is constantly seeking feedback and suggestions from users and the Haskell community. Based on the Beta period and the two months the IDE has officially been on the market, the feedback and activity on the IDE has been very positive. One Beta user, Armando Blancas, a Tools Engineer at Carrier IQ, Inc., commented, “My first impression of FP Haskell IDE is it has a well-designed and polished user interface that feels very intuitive and easy to explore. As a user, I like having things done for me. For example within the IDE, the platform is just there, auto-save, auto-compile, and a push-button program execution lets me just get on with my work.” Three levels of subscription are available. The first is the commercial Haskell platform, FP Haskell Center – Professional. The second is FP Haskell Center – Personal, which is designed for non-commercial programmers. Lastly, there is a free academic version for all current students and professors. Further reading http://www.fpcomplete.com/

EclipseFP is a set of Eclipse plugins to allow working on Haskell code projects. Its goal is to offer a fully featured Haskell IDE in a platform developers coming from other languages may already be familiar with. It provides the following features, among others: Cabal Integration

Provides a .cabal file editor, uses Cabal settings for compilation, allows the user to install Cabal packages from within the IDE. Can also use cabal-dev to provide sandboxing and project dependencies inside an Eclipse workspace. GHC Integration

Compilation is done via the GHC API, syntax coloring uses the GHC Lexer. Productive Coding

Quick fixes for common errors, warnings, and HLint suggestions. Automatic organization of imports. Autocompletion. Find and rename across modules and projects. Stylish-haskell integration for consistent code formatting. Debugging

Easy to launch GHCi sessions on any module with proper parameters. Manages breakpoints, the evaluation of variables and expressions uses the Eclipse debugging framework, and requires no knowledge of GHCi syntax. Also integrates with Yesod (launch the web application from EclipseFP). Running a program with profiling options results in profiling graphs being displayed in the UI for easy analysis. Browsing

The Haskell Browser perspective allows the user to navigate the list of packages and their documentation. It integrates seamlessly with Hackage. The Haskell module editor provides code folding, outline view of the module, popup of types and documentation mouse hovers, etc. Testing

EclipseFP integrates with Haskell test frameworks, most notably HTF, to provide UI feedback on test failures. The source code is fully open source (Eclipse License) on github and anyone can contribute. Current version is 2.5.5, released in October 2013, and more versions with additional features are planned and actively worked on. Most notably, version 2.6 should include support for Cabal 1.8 sandboxes. Feedback on what is needed is welcome! The website has information on downloading binary releases and getting a copy of the source code. Support and bug tracking is handled through Sourceforge forums and github issues. Further reading http://eclipsefp.github.com/

http://jpmoresmau.blogspot.com/

6.1.3 Ariadne Report by: Roman Cheplyaka Status: early development Ariadne is a new tool to provide the go-to-definition functionality for Haskell code. It is designed as a server which responds to queries from IDEs and text editor plugins. So far there’s only a plugin for vim, but we are looking forward to more editors and IDEs getting Ariadne support. The server uses the haskell-names name resolution library (→7.3.6). So it is fully Haskell-aware and can properly locate prefixed names (such as |T.head|) and locally bound names, which makes it much smarter than TAGS. Some of the future work directions are: finding definitions in other files (as of 0.1.2, Ariadne can only find definitions in the current file)

getting information from .cabal files (such as the language extensions and dependency information)

working with unsaved buffers Further reading Ariadne homepage: https://github.com/feuerbach/ariadne

Video demonstration: http://youtu.be/-sbGijbhxAc

ghc-mod is a backend command to enrich Haskell programming on editors including Emacs, Vim and Sublime. The ghc-mod package on Hackage includes the ghc-mod command and Emacs front-end. Emacs front-end provides the following features: Completion You can complete a name of keyword, module, class, function, types, language extensions, etc. Code template You can insert a code template according to the position of the cursor. For instance, “module Foo where” is inserted in the beginning of a buffer. Syntax check Code lines with error messages are automatically highlighted thanks to flymake. You can display the error message of the current line in another window. hlint can be used instead of GHC to check Haskell syntax. Document browsing You can browse the module document of the current line either locally or on Hackage. Expression type You can display the type/information of the expression on the cursor. There are two Vim plugins: ghcmod-vim

syntastic Here are new features: ghc-mod now supports the sandbox of cabal 1.18 and stopped supporting the sandbox of cabal-dev .

now supports the sandbox of 1.18 and stopped supporting the sandbox of . The ghc-mod package also provides a library now. Further reading http://www.mew.org/~kazu/proj/ghc-mod/en/

6.1.5 HEAT: The Haskell Educational Advancement Tool Report by: Olaf Chitil Status: active Heat is an interactive development environment (IDE) for learning and teaching Haskell. Heat was designed for novice students learning the functional programming language Haskell. Heat provides a small number of supporting features and is easy to use. Heat is distributed as a single, portable Java jar-file and works on top of GHCi. Version 5.05, with small improvements and bug-fixes, was released end of April 2013. Heat provides the following features: Editor for a single module with syntax-highlighting and matching brackets.

Shows the status of compilation: non-compiled; compiled with or without error.

Interpreter console that highlights the prompt and error messages.

If compilation yields an error, then the relevant source line is highlighted and no further expression can be evaluated in the console until the source has been changed and successfully recompiled.

A tree structure provides a program summary, giving definitions of types and types of functions.

Automatic checking of either Boolean or QuickCheck properties of a program; results shown in summary. Further reading http://www.cs.kent.ac.uk/projects/heat/

Refactorings are source-to-source program transformations which change program structure and organization, but not program functionality. Documented in catalogs and supported by tools, refactoring provides the means to adapt and improve the design of existing code, and has thus enabled the trend towards modern agile software development processes. Our project, Refactoring Functional Programs, has as its major goal to build a tool to support refactorings in Haskell. The HaRe tool is now in its seventh major release. HaRe supports full Haskell 2010, and is integrated with (X)Emacs. All the refactorings that HaRe supports, including renaming, scope change, generalization and a number of others, are module-aware, so that a change will be reflected in all the modules in a project, rather than just in the module where the change is initiated. Snapshots of HaRe are available from our GitHub repository (see below) and Hackage. There are related presentations and publications from the group (including LDTA’05, TFP’05, SCAM’06, PEPM’08, PEPM’10, TFP’10, Huiqing’s PhD thesis and Chris’s PhD thesis). The final report for the project appears on the University of Kent Refactoring Functional Programs page (see below). There is also a Google+ community called HaRe, and an IRC channel on freenode called #haskell-refactorer. Recent developments HaRe 0.7, which is a major change from 0.6 as it makes use of the GHC library for analysis, has been released; HaRe 0.7 is available on Hackage, and also downloadable from our GitHub page

HaRe 0.7 is alpha software, and comes with a limited number of refactorings, as the work so far has concentrated on getting the new architecture in place to make use of the GHC AST.

There is plenty to do, so anyone who has an interest is welcome to fork the repo and get stuck in.

Stephen Adams is starting his PhD at the University of Kent and will be working on data refactoring in Haskell. Further reading http://www.cs.kent.ac.uk/projects/refactor-fp/

https://github.com/alanz/HaRe

6.1.7 IHaskell: Haskell for Interactive Computing Report by: Andrew Gibiansky Status: very alpha (but usable!) IHaskell is an interactive interface for Haskell development, designed with the goal of replacing GHCi in some contexts. In addition to a simple REPL, it provides a notebook interface (in the style of Mathematica or Maple). The notebook interface runs in a browser and provides the user with editable cells in which they can create and execute code. The output of this code is displayed in a rich format right below, and if it’s not quite right, the user can go back, edit the cell, and re-execute. This rich format defaults to the same boring plain-text output as GHCi would give you; however, library authors will be able to define their own formats for displaying their data structures in a useful way, with the only limit being that the display output must be viewable in a browser (images, HTML, CSS, Javascript). For instance, integration with graphing libraries could produce in-browser data visualizations, while integration with Aeson’s JSON could produce a syntax-highlighted JSON output for complex data structures. Implementation-wise, IHaskell is a language kernel backend for the project known as IPython. Although it has the name “Python” in the name, IPython provides a language-agnostic protocol by which interactive code environments such as REPLs and notebooks can communicate with a language evaluator backend. IHaskell is a language kernel which uses ZeroMQ to communicate with IPython frontends and the GHC API to evaluate code. Although IHaskell is in very early stages, the future looks incredibly bright. Integration with popular Haskell libraries can give us beautiful and potentially interactive visualizations of Haskell data structures. On one hand, this could range from simple things such as foldable record structures — imagine being able to explore complex nested records by folding and unfolding bits and pieces at a time, instead of trying to mentally parse them from the GHCi output. On the other end, we could have interactive outputs, such as Parsec parsers which generate small input boxes that run the parser on any input they’re given. And these things are just the beginning — tight integration with IPython may eventually be able to provide things such as code-folding in your REPL or an integrated debugger interface. If this sounds good to you: contribute! We’re in dire need of developers to make this beautiful dream a reality, and I would be happy to help you get up to speed quickly. Further reading https://github.com/gibiansky/IHaskell

6.2 Code Management

Darcs is a distributed revision control system written in Haskell. In Darcs, every copy of your source code is a full repository, which allows for full operation in a disconnected environment, and also allows anyone with read access to a Darcs repository to easily create their own branch and modify it with the full power of Darcs’ revision control. Darcs is based on an underlying theory of patches, which allows for safe reordering and merging of patches even in complex scenarios. For all its power, Darcs remains a very easy to use tool for every day use because it follows the principle of keeping simple things simple. Our most recent release, Darcs 2.8.4 (with GHC 7.6 support), was in Februrary 2013. Some key changes in Darcs 2.8 include a faster and more readable darcs annotate , a darcs obliterate -O which can be used to conveniently “stash” patches, and hunk editing for the darcs revert command. Our work on the next Darcs release continues. In our sights are the new ‘darcs rebase‘ command (for merging and amending patches that would be hard to do with patch theory alone), the patch index optimisation (for faster local lookups on repositories with long histories), and the packs optimisation (for faster darcs get). This summer we have been lucky to get a chance to work on not just one, but two Google Summer of Code projects.(We participate in the Summer of Code under the Haskell.org umbrella, with an special agreement with Google to have an extra slot allocated for the purposes of Darcs work. This year, one of the Darcs related submissions was also selected in addition to the Darcs slot.) Our projects this year were on improving the local patch recording experience (Jose Neder), and the Darcs hub (BSRK Aditya). For the work on patch recording, Jose Neder brought three major improvements to the Darcs user interface: the patience diff algorithm, making patches much more reflective of human intention; automatic detection of file-move operations, and automatic detection of token replaces, resulting in patches that take better advantage of Darcs’ high-level representation of changes. As for the Darcs hub project (the Darcsden instance running on http://hub.darcs.net), BSRK Aditya has brought us a series of now live changes that make the hub easier to get up and running with. OAuth support means that users can now log in with their GitHub or Google accounts avoiding the need to create yet-another-password. A handful of nice new features make the site more useful than just a repository store: file edit for convenient quick edits, repository compare and patch bundle support for enhanced collaboration with forks, changes/annotate on files for better insight on the evolution of you code. Finally, the new build packs feature (see repository settings) enables an optimisation (GSoC 2010) which we hope will pave the way to much faster darcs get over networks. These changes have been merged into the mainline Darcs and Darcsden repositories, and are expected to available in the next stable release of Darcs. Darcs is free software licensed under the GNU GPL (version 2 or greater). Darcs is a proud member of the Software Freedom Conservancy, a US tax-exempt 501(c)(3) organization. We accept donations at http://darcs.net/donations.html. Further reading http://darcs.net

http://darcs.net/Development/Priorities

Post GSoC 2013 hub.darcs.net update http://joyful.com/blog/2013-09-26-darcsden-darcs-hub-gsoc-complete.html

6.2.2 DarcsWatch Report by: Joachim Breitner Status: working DarcsWatch is a tool to track the state of Darcs (→6.2.1) patches that have been submitted to some project, usually by using the darcs send command. It allows both submitters and project maintainers to get an overview of patches that have been submitted but not yet applied. DarcsWatch continues to be used by the xmonad project, the Darcs project itself, and a few developers. At the time of writing (November 2013), it was tracking 39 repositories and 4602 patches submitted by 248 users. Further reading http://darcswatch.nomeata.de/

http://darcs.nomeata.de/darcswatch/documentation.html

cab is a MacPorts-like maintenance command of Haskell cabal packages. Some parts of this program are a wrapper to ghc-pkg and cabal . If you are always confused due to inconsistency of ghc-pkg and cabal , or if you want a way to check all outdated packages, or if you want a way to remove outdated packages recursively, this command helps you. cab now supports the sandbox of cabal 1.18 and stopped supporting cabal-dev . Some new command-line options are added, including -j for parallel jobs, -p for library profiling and -e for executable profiling. Further reading http://www.mew.org/~kazu/proj/cab/en/

6.3 Deployment

6.3.1 Cabal and Hackage Report by: Duncan Coutts Background Cabal is the standard packaging system for Haskell software. It specifies a standard way in which Haskell libraries and applications can be packaged so that it is easy for consumers to use them, or re-package them, regardless of the Haskell implementation or installation platform. Hackage is a distribution point for Cabal packages. It is an online archive of Cabal packages which can be used via the website and client-side software such as cabal-install. Hackage enables users to find, browse and download Cabal packages, plus view their API documentation. cabal-install is the command line interface for the Cabal and Hackage system. It provides a command line program cabal which has sub-commands for installing and managing Haskell packages. Recent progress The Cabal packaging system has always faced growing pains. We have been through several cycles where we’ve faced chronic problems, made major improvements which bought us a year or two’s breathing space while package authors and users become ever more ambitious and start to bump up against the limits again. In the last few years we have gone from a situation where 10 dependencies might be considered a lot, to a situation now where the major web frameworks have a 100+ dependencies and we are again facing chronic problems. The Cabal/Hackage maintainers and contributors have been pursuing a number of projects to address these problems: The IHG sponsored Well-Typed (→8.1) to work on cabal-install resulting in a new package dependency constraint solver. This was incorporated into the cabal-install-0.14 release in the spring, and which is now in the latest Haskell Platform release. The new dependency solver does a much better job of finding install plans. In addition the cabal-install tool now warns when installing new packages would break existing packages, which is a useful partial solution to the problem of breaking packages. We had two Google Summer of Code projects on Cabal this year, focusing on solutions to other aspects of our current problems. The first is a project by Mikhail Glushenkov (and supervised by Johan Tibell) to incorporate sandboxing into cabal-install. In this context sandboxing means that we can have independent sets of installed packages for different projects. This goes a long way towards alleviating the problem of different projects needing incompatible versions of common dependencies. There are several existing tools, most notably cabal-dev , that provide some sandboxing facility. Mikhail’s project was to take some of the experience from these existing tools (most of which are implemented as wrappers around the cabal-install program) and to implement the same general idea, but properly integrated into cabal-install itself. We expect the results of this project will be incorporated into a cabal-install release within the next few months. The other Google Summer of Code project this year, by Philipp Schuster (and supervised by Andres Löh), is also aimed at the same problem: that of different packages needing inconsistent versions of the same common dependencies, or equivalently the current problem that installing new packages can break existing installed packages. The solution is to take ideas from the Nix package manager for a persistent non-destructive package store. In particular it lifts an obscure-sounding but critical limitation: that of being able to install multiple instances of the same version of a package, built against different versions of their dependencies. This is a big long-term project. We have been making steps towards it for several years now. Philipp’s project has made another big step, but there’s still more work before it is ready to incorporate into ghc, ghc-pkg and cabal. Looking forward Johan Tibell and Bryan O’Sullivan have volunteered as new release managers for Cabal. Bryan moved all the tickets from our previous trac instance into github, allowing us to move all the code to github. Johan managed the latest release and has been helping with managing the inflow of patches. Our hope is that these changes will increase the amount of contributions and give us more maintainer time for reviewing and integrating those contributions. Initial indications are positive. Now is a good time to get involved. The IHG is currently sponsoring Well-Typed to work on getting the new Hackage server ready for switchover, and helping to make the switchover actually happen. We have recruited a few volunteer administrators for the new site. The remaining work is mundane but important tasks like making sure all the old data can be imported, and making sure the data backup system is comprehensive. Initially the new site will have just a few extra features compared to the old one. Once we get past the deployment hurdle we hope to start getting more contributions for new features. The code is structured so that features can be developed relatively independently, and we intend to follow Cabal an