Index

Haskell Communities and Activities Report

Twenty-Ninth Edition – November 2015

Mihai Maruseac (ed.)

Andreas Abel

Chris Allen

Christopher Anand

Francesco Ariis

Heinrich Apfelmus

Emil Axelsson

Christiaan Baaij

Carl Baatz

Doug Beardsley

Jean-Philippe Bernardy

Alexander Berntsen

Joachim Breitner

Björn Buckwalter

Erik de Castro Lopo

Lucas DiCioccio

Manuel M. T. Chakravarty

Roman Cheplyaka

Olaf Chitil

Alberto Gomez Corona

Duncan Coutts

Atze Dijkstra

Péter Divianszky

Corentin Dupont

Richard Eisenberg

Tom Ellis

Maarten Faddegon

Andrew Farmer

Dennis Felsing

Julian Fleischer

Phil Freeman

PALI Gabor Janos

Michal J. Gajda

Andrew Gibiansky

Brett G. Giles

Andrew Gill

Alexander Granin

Mark Grebe

Daniel Gröber

Jurriaan Hage

Greg Hale

Bastiaan Heeren

Joey Hess

Nicu Ionita

Bob Ippolito

Robin KAY

Anton Kholomiov

Ian-Woo Kim

Oleg Kiselyov

Edward Kmett

Balazs K om uves

Eric Kow

Nickolay Kudasov

Rob Leslie

Ben Lippmeier

Andres Löh

Rita Loogen

Boris Lykah

Ian Lynagh

José Pedro Magalhães

Ketil Malde

Douglas McClean

Simon Michael

Mantas Markevicius

Dino Morelli

Natalia Muska

Rishiyur Nikhil

Antonio Nikishaev

Ulf Norell

Kiwamu Okabe

Ivan Perez

Jens Petersen

Haskell Consultancy Munich

Simon Peyton Jones

Matthew Pickering

Gracjan Polak

Bryan Richter

Jeffrey Rosenbluth

Ian Ross

David Sabel

Martijn Schrage

Carter Tazio Schonwald

Tom Schrijvers

Michael Schröder

Austin Seipp

Jeremy Shaw

Christian Höner zu Siederdissen

Aditya Siram

Gideon Sireling

Jim Snow

Michael Snoyman

Kyle Marek-Spartz

Lennart Spitzner

Doaitse Swierstra

Henk-Jan van Tuyl

Bernhard Urban

Alessio Valentini

Adam Vogt

Daniel Wagner

Greg Weber

Ingo Wechsung

Kazu Yamamoto

Edward Z. Yang

Brent Yorgey

Alan Zimmerman

Marco Zocca

Preface

This is the 29th edition of the Haskell Communities and Activities Report.

Quite a lot of things changed since the previous report. Some old entries have resurfaced and contributors submitted stories in new areas of development but, sadly, several entries have become too stale and had to be removed. All entries from 2013 except the one about cabal have been removed for now but we hope to see them resurface again on the next edition. Please do revive such entries next time if you do have news on them.

To make contributing easier, we are experimenting with moving to a rolling-deadline submission where each entry can be submitted at any moment of the year. However, we will still have only 2 editions of HCAR per year, at the usual pace, only the entry submission period will be extended. This change allows us to change the pipeline for building the report (thus, the next report might look completely different). Hence, we are also considering opening the building pipeline to be used by any submitter.

As usual, fresh entries – either completely new or old entries which have been revived after a short temporarily disappearance – are formatted using a blue background, while updated entries have a header with a blue background.

A few words from Mihai: The previous issue of HCAR was the last in which Alejandro helped in editing. Due to other obligations he has decided to step down. I want to thank him for the effort so far and for the contributions to the Haskell world.

A call for new HCAR entries and updates to existing ones will be issued on the Haskell mailing lists in late March/early April.

Now enjoy the current report and see what other Haskellers have been up to lately. Any feedback is very welcome, as always.

Mihai Maruseac, University of Massachusetts Boston, US

<hcar at haskell.org>

1 Community

1.1 Haskellers Report by: Michael Snoyman Status: experimental 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. Haskellers is a web site in maintenance mode. No new features are being added, though the site remains active with many new accounts and job postings continuing. If you have specific feature requests, feel free to send them in (especially with pull requests!). 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. Further reading http://www.haskellers.com/

2 Books, Articles, Tutorials

The collection of various Haskell mini tutorials and assorted small projects (http://okmij.org/ftp/Haskell/) has received three additions: Generators: yield = exception + non-determinism Generators, familiar nowadays from Python (although they predate Python by about two decades) are the expressions that |yield|. They give the benefit of lazy evaluation – modular on-demand processing – in strict languages or when lazy evaluation does not apply because the computation has observable effects such as IO. The tutorial explains that |yield| decomposes into exceptions and non-determinism. The one-line definition should clarify: yield :: MonadPlus m => e -> EitherT e m ()

yield x = raise x `mplus` return ()



The exception carries the |yield|’s argument ‘out of band’, on the emergency channel so to speak; the non-deterministic choice |mplus| effectively lets the computation continue despite raising the exception. We have unwittingly obtained the typing of generators: |MonadPlus m => EitherT e m a| is the type of a generator returning the result of type |a| while yielding intermediate results of type |e|.

The tutorial derives the above definition by equational reasoning. It also documents the rich history of generators.

Read the tutorial online.

Icon-like generators in Haskell

The decomposition of |yield| into exceptions and non-determinism sprouts the implementations of generators in Haskell, logical programming and ML – the implementations that are correct and working on the first try. As an illustration, the tutorial shows how to use Haskell as if it were Icon. For example, the following Icon code procedure findodd(s1, s2)

every i := find(s1, s2) do

if i % 2 = 1 then suspend i

end

that produces all odd indices at which string |s1| occurs within |s2| looks in Haskell as follows findodd2 :: (Monad m, LogicT t, MonadPlus (t m)) =>

String -> String -> EitherT Int (t m) ()

findodd2 s1 s2 = iterE Nothing $ do

i <- findIM s1 s2

if i `mod` 2 == 1 then yield i else return ()|])



Read the tutorial online.

Generator from any Foldable

Any abstract data type that implements the |Data.Foldable| interface implements the generator interface. In fact, any (collection) type |T| with the operation like |mapM_ :: Monad m => (Element T -> m b) -> T -> m ()| that lets a monadic action examine its elements (of the type |Element T|) implements the generator interface. The claims holds regardless of the implementation of the data type, whether it is a data structure or if the elements to traverse are computed on-the-fly.

The proof of the claim is constructive, short, and trivial: foldable_gen :: (MonadPlus m, F.Foldable t) =>

t a -> EitherT a m ()

foldable_gen = F.mapM_ yield



The type says it all: any Foldable is a generator.

Read the tutorial online.

2.2 School of Haskell Report by: Natalia Muska Participants: Michael Snoyman, Edward Kmett, Simon Peyton Jones and others Status: active The School of Haskell has been available since early 2013. It’s main two functions are to be an education resource for anyone looking to learn Haskell and as a sharing resources for anyone who has built a valuable tutorial. The School of Haskell contains tutorials, courses, and articles created by both the Haskell community and the developers at FP Complete. Courses are available for all levels of developers. Two new features were added to the School of Haskell. First is the addition of Disqus for commenting on each tutorial and highlighting other potentially interesting tutorials. Second is the inclusion of autorun tags. This enables users to run a snippet as soon as they open a tutorial. Currently 3150 tutorials have been created (a 125%increase from this time last year) and 441 have been officially published (a 53%increase from this time last year). Some of the most visited tutorials are Text Manipulation Attoparsec, Learning Haskell at the SOH, Introduction to Haskell - Haskell Basics, and A Little Lens Starter Tutorial. Over the past year the School of Haskell has averaged about 16k visitors a month. 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. Further reading https://www.fpcomplete.com/school

2.3 Haskell Programming from first principles, a book forall Report by: Chris Allen Participants: Julie Moronuki Status: In progress, content complete soon Haskell Programming is a book that aims to get people from the barest basics to being well-grounded in enough intermediate Haskell concepts that they can self-learn what would be typically required to use Haskell in production or to begin investigating the theory and design of Haskell independently. We’re writing this book because many have found learning Haskell to be difficult, but it doesn’t have to be. What particularly contributes to the good results we’ve been getting has been an aggressive focus on effective pedagogy and extensive testing with reviewers as well as feedback from readers. My coauthor Julie Moronuki is a linguist who’d never programmed before learning Haskell and authoring the book with me. Haskell Programming is currently about 70 percent complete and is 912 pages long in the v0.7.0 release. The book is available for sale during the early access, which includes the 1.0 release of the book in PDF. We’re still doing the main block of writing and testing of material. We’ve got some unannounced material that we think will excite people a bit as well. Further reading http://haskellbook.com

https://superginbaby.wordpress.com/2015/05/30/learning-haskell-the-hard-way/

http://bitemyapp.com/posts/2015-08-23-why-we-dont-chuck-readers-into-web-apps.html

2.4 Learning Haskell Report by: Manuel M. T. Chakravarty Participants: Gabriele Keller Status: Work in progress with four published chapters Learning Haskell is a new Haskell tutorial that integrates text and screencasts to combine in-depth explanations with the hands-on experience of live coding. It is aimed at people who are new to Haskell and functional programming. Learning Haskell does not assume previous programming expertise, but it is structured such that an experienced programmer who is new to functional programming will also find it engaging. Learning Haskell combines perfectly with the Haskell for Mac programming environment, but it also includes instructions on working with a conventional command-line Haskell installation. It is a free resource that should benefit anyone who wants to learn Haskell. Learning Haskell is still work in progress, but the first four chapters are already available. The latest chapter illustrates various recursive structures using fractal graphics, such as this fractal tree. Further chapters will be made available as we complete them. Further reading Learning Haskell is free at http://learn.hfm.io

is free at http://learn.hfm.io Blog post with some background: http://blog.haskellformac.com/blog/learning-haskell

2.5 Agda Tutorial Report by: Péter Divianszky Participants: Ambrus Kaposi, students at ELTE IK Status: experimental 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. 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. Further reading http://people.inf.elte.hu/divip/AgdaTutorial/Index.html

3 Implementations

GHC development spurs on, with an exciting new announcement - the next release will be a super-major one, culminating in GHC 8.0. There are many reasons for this change, but one of the most exciting is that GHC is getting a completely new core language. While this adds a bit of complexity to the compiler, it paves the way to implement Dependent Haskell over the course of the next few years. Major changes in GHC 8.0.1 Support for simple, implicit callstackas with source locations and implicit parameters providing callstacks/source locations, allowing you to have a light-weight means of getting a call-stack in a Haskell application. Improved optimization diagnostics The compiler is now more liberal about issues warnings of potentially non-firing rewrite rules and other potential gotchas. Support for wildcards in data and type family instances Injective type families Injective TFs allow you to specify type families which are injective, i.e. have a one-to-one relationship. Applicative do notation With the new |-XApplicativeDo|, GHC tries to desugar do-notation to |Applicative| where possible, giving a more convenient sugar for many common |Applicative| expressions. Support for deriving the |Lift| typeclass - a very common need when working with Template Haskell. A PowerPC 64bit code generator The new native codegen supports Linux/ppc64 in both big endian and little endian mode. A beautiful new users guide Now rewritten in reStructured Text, and with significantly improved output and documentation. Visible type application This allows you to say, for example |id @Bool| to specialize |id| to |Bool -> Bool|. With this feature, proxies are never needed. Kind Equalities , which form the first step to building Dependent Haskell. This feature enables promotion of GADTs to kinds, kind families, heterogeneous equality (kind-indexed GADTs), and |* :: *|. Strict Haskell support This includes new |-XStrictData| and |-XStrict| language extensions. Support for record pattern synonyms Implement phase 1 of the MonadFail proposal Overloaded record fields At long last, ORF will finally be available in GHC 8.0, allowing multiple uses of the same field name and a form of type-directed name resolution. A huge improvement to pattern matching (including much better coverage of GADTs), based on the work of Simon PJ and Georgios Karachalias. More Backpack improvements There’s a new user-facing syntax which allows multiple modules to be defined a single file, and we’re hoping to release at least the ability to publish multiple “units” in a single Cabal file. Support for DWARF based stacktraces from Peter Wortmann, Arash Rouhani, and Ben Gamari with backtraces from Haskell code. A better LLVM backend We’re planning on a major build system change that will ship GHC 8.0 with a pre-baked copy of LLVM 3.7.0, that ships with every major Tier 1 platform. Big GC improvements for large, 64-bit workloads , motivated by work Simon Marlow has been doing at Facebook. If you have a GC-intensive workload with large heaps, GHC 8.0.1 should hopefully lower latency and collection time for your applications. Upcoming post 8.0 plans Naturally, there were several things we didn’t get around to this cycle, or things which are still in flight and being worked on. (And you can always try to join us if you want something done!) Libraries, source language, type system A new, type-indexed type representation, data |TTypeRep (a :: k)|. See |TypeableT|.

Support for Type Signature Sections , allowing you to write |(:: ty)| as a shorthand for |( -> x :: ty)|.

, allowing you to write |(:: ty)| as a shorthand for |( -> x :: ty)|. A |DEPRECATED| pragma for exports

Further work on Dependent Haskell, including pi types. Back-end and runtime system More DWARF improvements, including experimentations in new performance tools!

Work continues on GHC on ARM, and more recently, GHC on AArch64! 8.0 is leagues ahead of 7.10, but there is still much to be done.

We’re working on integrating support for Compact Normal Forms, described in an ICFP 2015 paper. CNFs are designed for the use case of transmitting large data structures across applications, without paying for costly serialization. Frontend, build-system and miscellaneous changes A planned overhaul of GHC’s build system to use Shake instead of Make is still in play, although it didn’t make it in time for 8.0.1

A new Mac Mini will be added to our continuous integration suite, thanks to a generous donation from Futurice!

Work on a new set of flags, |-Wcompat|, is underway, hoping to bring some order to the chaos of code-breaking language updates, and the implications these have for |-Wall| clean codebases.

Work steams on to make GHC a deterministic compiler - always producing the same output object files for the same input. This has proven to be surprisingly tricky, but we just needed a smart hacker to step up and tackle it - and Bartosz Nitka has decided to do just that! Development updates and getting involved GHC is as busy as ever, and the amount of patches we review and contributors we actively get has been steadily increasing. In particular, Ben Gamari from Well-Typed has joined Austin in ongoing GHC maintenance, patch review, and guidance. But GHC is far, far too large for even a few paid individuals to fully manage it. As always, if you want something done, you should get involved and talk to us! Since the last release, we’ve continued to see some major effort expended by new contributors. Matthew Pickering has lead the way on major improvements to the state of pattern synonyms, Ömer Sinan Agacan has been tirelessly working on multiple parts of the compiler, and Thomas Miedema has continued with seemingly endless energy to improve all areas of GHC. Of course, it would be even better if your name were included here! So if you’ve got a few spare cycles - we could always use more helping hands... Links: https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations

https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo

https://ghc.haskell.org/trac/ghc/wiki/Building/Shake

https://ghc.haskell.org/trac/ghc/wiki/DWARF

https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1

https://ghc.haskell.org/trac/ghc/wiki/DistributedHaskell

https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations

https://ghc.haskell.org/trac/ghc/wiki/ExplicitTypeApplication

https://ghc.haskell.org/trac/ghc/wiki/GhcApi

https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend

https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies

https://ghc.haskell.org/trac/ghc/wiki/OverloadedRecordFields

https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures

https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker

https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields

https://ghc.haskell.org/trac/ghc/wiki/StaticPointers

https://ghc.haskell.org/trac/ghc/wiki/Typeable

https://ghc.haskell.org/trac/ghc/wiki/prelude710

http://www.seas.upenn.edu/~eir/papers/2013/fckinds/fckinds-extended.pdf

https://github.com/yav/type-nat-solver/raw/master/docs/paper.pdf

https://github.com/yav/type-nat-solver

http://ezyang.com/papers/ezyang15-cnf.pdf

3.2 Ajhc Haskell Compiler Report by: Kiwamu Okabe Participants: John Meacham, Hiroki Mizuno, Hidekazu Segawa, Takayuki Muranushi 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 http://www.slideshare.net/master_q/20131020-osc-tokyoajhc. Ajhc is, so to speak, an accelerator to develop jhc. Demonstrations https://www.youtube.com/watch?v=XEYcR5RG5cA NetBSD kernel’s HD Audio sound driver has interrupt handler. The interrupt handler of the demo is re-written by Haskell language using Ajhc. At the demo, run following operations. First, set breakpoint at the interrupt of finding headphone, and see Haskell function names on backtrace. Second, set breakpoint s_alloc() function, that allocate area in Haskell heap. Make sure of calling the function while anytime running kernel. Nevertheless, playing wav file does not break up. The source code is found at https://github.com/metasepi/netbsd-arafura-s1 The interrupt handler source code at https://github.com/metasepi/netbsd-arafura-s1/blob/fabd5d64f15058c198ba722058c3fb89f84d08a5/metasepi/sys/hssrc/Dev/Pci/Hdaudio/Hdaudio.hs#L15. Discussion on mailing list: http://www.haskell.org/pipermail/haskell-cafe/2014-February/112802.html 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 Maintain Ajhc as compilable with latast GHC. License Runtime: MIT License https://github.com/ajhc/ajhc/blob/master/rts/LICENSE

Haskell libraries: MIT License https://github.com/ajhc/ajhc/blob/master/lib/LICENSE

The others: GPLv2 or Later https://github.com/ajhc/ajhc/blob/arafura/COPYING 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

3.3 The Helium Compiler Report by: Jurriaan Hage Participants: Bastiaan Heeren Helium is a compiler that supports a substantial subset of Haskell 98 (but, e.g., n+k patterns are missing). Type classes are restricted to a number of built-in type classes and all instances are derived. The advantage of Helium is that it generates novice friendly error feedback, including domain specific type error diagnosis by means of specialized type rules. Helium and its associated packages are available from Hackage. Install it by running cabal install helium . You should also cabal install lvmrun on which it dynamically depends for running the compiled code. Currently Helium is at version 1.8.1. The major change with respect to 1.8 is that Helium is again well-integrated with the Hint programming environment that Arie Middelkoop wrote in Java. The jar-file for Hint can be found on the Helium website, which is located at http://www.cs.uu.nl/wiki/Helium. This website also explains in detail what Helium is about, what it offers, and what we plan to do in the near and far future. A student has added parsing and static checking for type class and instance definitions to the language, but type inferencing and code generating still need to be added. Completing support for type classes is the second thing on our agenda, the first thing being making updates to the documentation of the workings of Helium on the website.

UHC is the Utrecht Haskell Compiler, supporting almost all Haskell98 features and most of Haskell2010, plus experimental extensions. StatusCurrent active development directly on UHC: Making intermediate Core language available as a compilable language on its own, used by an experimental Agda backend (Philipp Hausmann).

The platform independent part of UHC has been made available via Hackage, as package “uhc-light” together with a small interpreter for Core files (Atze Dijkstra, interpreter still under development).

Implementing static analyses (Tibor Bremer, Jurriaan Hage, in progress).

Rework of the type system (Alejandro Serrano, Jurriaan Hage, just started). 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

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

3.5 Frege Report by: Ingo Wechsung Participants: Dierk König, Mark Perry, Marimuthu Madasami, Sean Corfield, Volker Steiss and others Status: actively maintained Frege is a Haskell dialect for the Java Virtual Machine (JVM). It covers essentially Haskell 2010, though there are some mostly insubstantial differences. Several GHC language extensions are supported, most prominently higher rank types. As Frege wants to be a practical JVM language, interoperability with existing Java code is essential. To achieve this, it is not enough to have a foreign function interface as defined by Haskell 2010. We must also have the means to inform the compiler about existing data types (i.e. Java classes and interfaces). We have thus replaced the FFI by a so called native interface which is tailored for the purpose. The compiler, standard library and associated tools like Eclipse IDE plugin, REPL (interpreter) and several build tools are in a usable state, despite development is actively ongoing. The compiler is self hosting and has no dependencies except for the JDK. In the growing, but still small community, a consensus developed this summer that existing differences to Haskell shall be eliminated. Ideally, Haskell source code could be ported by just compiling it with the Frege compiler. Thus, the ultimate goal is for Frege to become the Haskell implementation on the JVM. Already, in the last month, three of the most offending syntactical differences have been removed: lambda syntax, instance/class context syntax and recognition of True and False as boolean literals. Frege is available under the BSD-3 license at the GitHub project page. A ready to run JAR file can be downloaded or retrieved through JVM-typical build tools like Maven, Gradle or Leiningen. All new users and contributors are welcome! Currently, we develop a new backend of the compiler to support and employ Java 8 lambdas. In addition, several contributors are porting or re-implementing GHC libraries, like Array or STM. Further reading https://github.com/Frege/frege

3.6 Specific Platforms

The FreeBSD Haskell Team is a small group of people 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 x86 and x86_64) starting from GHC 6.12.1, hence one can always download native vanilla binary distributions for each new release. We have a developer (staging) repository for Haskell ports that currently features around 600 of many of the popular Cabal packages. Most of the updates committed to that repository are continuously integrated to the official ports tree on a regular basis. In result, the FreeBSD Ports Collection still offers many popular and important Haskell software: GHC 7.10.2, Gtk2Hs, wxHaskell, XMonad, Pandoc, Gitit, Yesod, Happstack, Snap, Agda (along with its standard library), git-annex, and so on – all of them are available on 9.3-RELEASE and 10.2-RELEASE. Note that we decided to abandon tracking Haskell Platform (although all its former components are still there as individual packages), instead we updated the packages to match their versions on Stackage (at end of August). If you find yourself interested in helping us or simply want to use the latest versions of Haskell programs on FreeBSD, check out our development repository on GitHub (see below) where you can find the latest versions of the ports together with all the important pointers and information required for contacting or contributing. Further reading https://github.com/freebsd-haskell/ports

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 741 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 just released stable Debian release (“jessie”) provides the Haskell Platform 2013.2.0.0 and GHC 7.6.3, while in Debian unstable, we ship GHC 7.8.4. GHC 7.10.2, together with all libraries, is ready to be used in Debian experimental, and should be uploaded to unstable shortly. Debian users benefit from the Haskell ecosystem on 14 architecture/kernel combinations, including the non-Linux-ports KFreeBSD and Hurd. Further reading http://wiki.debian.org/Haskell

3.6.3 Fedora Haskell SIG Report by: Jens Petersen Participants: Ricky Elrod, Ben Boeckel, and others Status: active The Fedora Haskell SIG works to provide good Haskell support in the Fedora Project Linux distribution. Fedora 22 is about to be released. Updating to ghc-7.8.4 turned out to be a lot of work. Some packages now have static subpackages for portability: alex, cabal-install, pandoc, and darcs. Lots of Haskell packages were updated to their latest versions (see “Package changes” below). Fedora 23 development is starting: we are considering if we can update to ghc-7.10 if there is a bugfix release in time, and to refresh packages to their latest versions tracking Stackage where possible. In the meantime there is a ghc-7.10.1 Fedora Copr repo available for Fedora 20+ and EPEL 7. At the time of writing we have 314 Haskell source packages in Fedora. The cabal-rpm packaging tool has improved further with a new update command, dnf support, and various bugfixes and improvements. If you are interested in Fedora Haskell packaging, please join our mailing-list and the Freenode #fedora-haskell channel. You can also follow @fedorahaskell for occasional updates. Further reading Homepage: http://fedoraproject.org/wiki/Haskell_SIG

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/f21-f22.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.4.0 in June 2014 a lot has happened in the Agda project and community. For instance: There have been two Agda courses at the Oregon Programming Languages Summer School (OPLSS). In 2014 by Ulf Norell, and in 2015 by Peter Dybjer.

Agda has moved to github: https://github.com/agda/agda.

Agda 2.4.2 was released in September 2014, and the latest stable version is Agda 2.4.2.4, released in September 2015.

The restriction of Agda to not use Streicher’s Axiom K was proved correct by Jesper Cockx et al. in the ICFP 2014 paper Pattern Matching without K .

. Instance arguments are now powerful enough to emulate Haskell-style type classes.

The reflection machinery has been extended, making it possible to define convenient reflection based tactics.

Improved compiler performance, and a new backend targeting the Utrecht Haskell Compiler (UHC). Release of Agda 2.4.4 is planned for early 2016. Release of Agda 2.4.4 is planned for early 2016. Further reading The Agda Wiki: http://wiki.portal.chalmers.se/agda/

4.2 MiniAgda Report by: Andreas Abel Status: experimental 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. MiniAgda is now hosted on http://hub.darcs.net/abel/miniagda. MiniAgda is available as Haskell source code on hackage and compiles with GHC 6.12.x – 7.8.2. Further reading http://www.cse.chalmers.se/~abela/miniagda/

4.3 Disciple Report by: Ben Lippmeier Participants: Ben Lippmeier, Amos Robinson, Erik de Castro Lopo, Kyle van Berendonck Status: experimental, active development The Disciplined Disciple Compiler (DDC) is a research compiler used to investigate program transformation in the presence of computational effects. It compiles a family of strict functional core languages and supports region, effect and closure typing. This extra information provides a handle on the operational behaviour of code that isn’t available in other languages. Programs can be written in either a pure/functional or effectful/imperative style, and one of our goals is to provide both styles coherently in the same language. What is new? DDC is in an experimental, pre-alpha state, though parts of it do work. In March this year we released DDC 0.4.1, with the following new features: Added a bi-directional type inferencer based on Joshua Dunï¬eld and Neelakantan Krishnaswami’s recent ICFP paper.

Added a region extension language construct, and coeffect system.

Added the Disciple Tetra language which includes infix operators and desugars into Disciple Core Tetra.

Compilation of Tetra and Core Tetra programs to C and LLVM.

Early support for rate inference in Core Flow.

Flow fusion now generates vector primops for maps and folds.

Support for user-defined algebraic data types.

Civilized error messages for unsupported or incomplete features.

Most type error messages now give source locations.

Building on Windows platforms.

Better support for foreign imported types and values.

Changed to Git for version control. Further reading http://disciple.ouroborus.net

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. 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. The remote data concept can also be used to compose skeletons in an elegant and effective way, especially in distributed settings. 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 version based on GHC-7.8.2 (including binary packages and prepared source bundles) has been released in April 2014. This version fixed a number of issues related to error shut-down and recovery, and featured extended support for serialising Haskell data structures. The release of a version based on GHC-7.10 is in preparation. Previous stable releases with binary packages and bundles are 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. Please contact us if you need any support. 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. Eden’s thread view can also be used to visualise ghc eventlogs. Recently, in the course of his Bachelor thesis, Bastian Reitemeier developed another trace viewer tool, Eden-Tracelab, which is capable of visualising large trace files, without being constrained by the available memory. Details can be found in his blogpost http://brtmr.de/2015/10/17/introducing-eden-tracelab.html. 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 Lidia Sanchez-Gil: On the equivalence of operational and denotational semantics for parallel functional languages , PhD Thesis, Facultad de Informatica, Universidad Complutense de Madrid, July 2015. http://eprints.ucm.es/33213/

, PhD Thesis, Facultad de Informatica, Universidad Complutense de Madrid, July 2015. http://eprints.ucm.es/33213/ Bastian Reitemeier: Analysis of Large Eden Trace Files , Bachelor Thesis, Philipps-Universitat Marburg, October 2015.

, Bachelor Thesis, Philipps-Universitat Marburg, October 2015. Thomas Horstmeyer: Smarter Communication Channels , Pre-Symposium Proceedings of IFL 2015, Sept. 2015.

, Pre-Symposium Proceedings of IFL 2015, Sept. 2015. Lukas Schiller: A functional view of BatcherÂs bitonic sorting network , Pre-Symposium Proceedings of IFL 2015, Sept. 2015.

, Pre-Symposium Proceedings of IFL 2015, Sept. 2015. M. Dieterle, Th. Horstmeyer, R. Loogen, J. Berthold: Skeleton Composition vs Stable Process Systems in Eden , submitted for publication

, submitted for publication J. Berthold, H.-W. Loidl, K. Hammond: PAEAN: Portable Runtime Support for Physically-Shared-Nothing Architectures in Parallel Haskell Dialects, submitted for publication Further reading http://www.mathematik.uni-marburg.de/~eden

The Wakarusa project is a domain-specific language toolkit, that makes domain-specific languages easier to deploy in high-performance scenarios. The technology is going to be initially applied to two types of high-performance platforms, GPGPUs and FPGAs. However, the toolkit will be general purpose, and we expect the result will also make it easier to deploy DSLs in situations where resource usage needs to be well-understand, such as cloud resources and embedded systems. The project is funded by the NSF. Wakarusa is a river just south of Lawrence, KS, where the main campus of the University of Kansas is located. Wakarusa is approximately translated as “deep river”, and we use deep embeddings a key technology in our DSL toolkit. Hence the project name Wakarusa. A key technical challenge with syntactic alternatives to deep embeddings is knowing when to stop unfolding. We are using a new design pattern, called the remote monad (→6.5.7), which allows a monad to be virtualized, and run remotely, to bound our unfolding. We have already used remote monads for graphics (Blank Canvas), hardware bus protocols (λ-bridge), a driver for MineCraft, an implementation of JSON-RPC, and a compiler for the Arduino (→6.1.8). Using the remote monad design pattern, and HERMIT, we are developing a translation framework that translates monadic Haskell to GPGPUs (building on accelerate), and monadic Haskell to Hardware (building on Kansas Lava), and monadic imperative Haskell to Arduino C. Further reading https://github.com/ku-fpg/wakarusa

http://ku-fpg.github.io/research/wakarusa/

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 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.2) 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), MFlow (continuation-based) and dingo (GUI). The Scotty (→5.2.3) 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. Since the last HCAR, WAI has successfully released version 3.0, which removes dependency on any specific streaming data framework. A separate wai-conduit package provides conduit bindings, and such bindings can easily be provided for other streaming data frameworks. The WAI community continues to grow, with new applications and web frameworks continuing to be added. We’ve recently started a new mailing list to discuss WAI related topics. Interested parties are strongly encouraged to join in! Further reading http://www.yesodweb.com/book/wai

https://groups.google.com/d/forum/haskell-wai

5.2.2 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.1) — 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.1). 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 (→5.2.3). The new 1.4 release of Yesod is almost a completely backwards-compatible change. The version bump was mostly performed to break compatibility with older versions of dependencies, which allowed us to remove approximately 500 lines of conditionally compiled code. Notable changes in 1.4 include: New routing system with more overlap checking control.

yesod-auth works with your database and your JSON.

yesod-test sends HTTP/1.1 as the version.

Type-based caching with keys. The Yesod team is quite happy with the current level of stability in Yesod. Since the 1.0 release, Yesod has maintained a high level of API stability, and we intend to continue this tradition. 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. GHCJS support is in the works. 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.1) source code: (https://github.com/snoyberg/haskellers). Further reading http://www.yesodweb.com/

Scotty is a Haskell web framework inspired by Ruby’s Sinatra, using WAI (→5.2.1) and Warp (→5.2.4), and is designed to be a cheap and cheerful way to write RESTful, declarative web applications. A page is as simple as defining the verb, url pattern, and Text content.

It is template-language agnostic. Anything that returns a Text value will do.

Conforms to WAI Application interface.

Uses very fast Warp webserver by default. The goal of Scotty is to enable the development of simple HTTP/JSON interfaces to Haskell applications. Implemented as a monad transformer stack, Scotty applications can be embedded in arbitrary MonadIOs. The Scotty API is minimal, and fully documented via haddock. The API has recently remained stable, with a steady stream of improvements contributed by the community. Further reading Hackage: http://hackage.haskell.org/package/scotty

Github: https://github.com/scotty-web/scotty

5.2.4 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 followed WAI in its move from conduit to a lower level streaming data abstraction. We’ve additionally continued work on more optimizations, and improved support for power efficiency by using the auto-update package. 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

Mighttpd (called mighty) version 3 is a simple but practical Web server in Haskell. It provides features to handle static files, redirection, CGI, reverse proxy, reloading configuration files and graceful shutdown. Also TLS is experimentally supported. Since Warp supports HTTP/2, Mighttpd 3 is able to serve in HTTP/2 (if TLS is enabled) as well as HTTP/1.1. You can install Mighttpd 3 (mighttpd2) from HackageDB. Note that the package name is mighttpd2, not mighttpd3, for historical reasons. Further reading http://www.mew.org/~kazu/proj/mighttpd/en/

http://www.yesodweb.com/blog/2015/07/http2

Happstack is a very fine collection of libraries for creating web applications in Haskell. We aim to leverage the unique characteristics of Haskell to create a highly-scalable, robust, and expressive web framework. Over the past year, much development has been focused on the higher-level components such as a rewrite of the happstack-authentication library and work on unifying the various stripe bindings into a single authoritative binding. Over the next year we hope to get back to the core and focus on hyperdrive , a new low-level, trustworthy HTTP backend, as well as focusing on developing and deploying applications using nixops . Further reading http://www.happstack.com/

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

The Snap Framework is a web application framework built from the ground up for speed, reliability, stability, 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. If you would like to contribute, get a question answered, or just keep up with the latest activity, stop by the #snapframework IRC channel on Freenode. Further reading Snaplet Directory: http://snapframework.com/snaplets

http://snapframework.com

5.2.8 MFlow Report by: Alberto Gomez Corona Status: active development MFlow is a Web framework of the kind of other functional, stateful frameworks like WASH, Seaside, Ocsigen or Racket. MFlow does not use continuation passing properly, but a backtracking monad that permits the synchronization of browser and server and error tracing. This monad is on top of another “Workflow” monad that adds effects for logging and recovery of process/session state. In addition, MFlow is RESTful. Any GET page in the flow can be pointed to with a REST URL. The navigation as well as the page results are type safe. Internal links are safe and generate GET requests. POST request are generated when formlets with form fields are used and submitted. It also implements monadic formlets: They can modify themselves within a page. If JavaScript is enabled, the widget refreshes itself within the page. If not, the whole page is refreshed to reflect the change of the widget. MFlow hides the heterogeneous elements of a web application and expose a clear, modular, type safe DSL of applicative and monadic combinators to create from multipage to single page applications. These combinators, called widgets or enhanced formlets, pack together javascript, HTML, CSS and the server code. [1]. A paper describing the MFlow internals has been published in The Monad Reader issue 23 [2] The use of backtracking to solve ”the integration problem”. It happens when the loose coupling produce exceptional conditions that may trigger the rollback of actions in the context of failures, shutdowns and restart of the systems (long running processes). That has been demonstrated using MFlow in [3]. A web application can be considered as an special case of integration. MFlow pack the elements of a web aplication within composable widgets. This ”deep integration” is the path followed by the software industry to create from higher level framewors to operating systems [4] perch[5] and hplayground are two new packages that make run the page logic of MFlow in the Web Browser using Haste, the Haskell-to-JavaScript compiler. perch has the syntax of blaze-html and hplayground uses the syntax and primitives of the View Monad. Both permit the page logic of MFlow to run fully in the Web Browser. Under the same syntax, they are completely different. It generates trees by calling DOM primitives directly. While string builders are unary tree constructors, perch uses a generalized builder for n-trees. It also has combinators for the modification of elements and it can assign perch event handlers to elements and it has also JQuery-like operations. It can be used alone for the creation of client-side applications. Perch run in Haste and has been ported to GHCJS by Arthur Fayzrakhmanov. hplayground is a monadic functional reactive[6] framework with MFlow syntax that permits the creation of seamless client-side applications. it uses the Transient monad. hplayground can sequence perch renderings with events. It is possible to construct composable monadic and applicative formlets with validations, and event handling included these formlets may modify his own rendering. There is a site with example Haste-perch-hplayground (made with MFlow) online[6] . There is also a tutorial for the creation of Client-side applications, that describe the structure of a small accounting application for haskell beginners[7]. Since the events are handled locally but there are no event handlers, Monadic Reactive may be a better alternative to functional Reactive in the creation of seamless Web Browser applications whenever there are many dynamic DOM updates[8]. Future work: To port hplayground to GHCJS. To manage client-side applications as nodes in the cloud using websockets and transient. Further reading MFlow as a DSL for web applications https://www.fpcomplete.com/school/to-infinity-and-beyond/older-but-still-interesting/MFlowDSL1

MFlow, a continuation-based web framework without continuations http://themonadreader.wordpress.com/2014/04/23/issue-23

How Haskell can solve the integration problem https://www.fpcomplete.com/school/to-infinity-and-beyond/pick-of-the-week/how-haskell-can-solve-the-integration-problem

Towards a deeper integration: A Web language: http://haskell-web.blogspot.com.es/2014/04/towards-deeper-integration-web-language.html

Perch https://github.com/agocorona/haste-perch

hplayground demos http://tryplayg.herokuapp.com

haste-perch-hplaygroun tutorial http://www.airpair.com/haskell/posts/haskell-tutorial-introduction-to-web-apps

react.js a solution for a problem that Haskell can solve in better ways http://haskell-web.blogspot.com.es/2014/11/browser-programming-reactjs-as-solution.html

MFlow demo site: http://mflowdemo.herokuapp.com

5.2.9 Sunroof Report by: Andrew 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.10 Blank Canvas Report by: Andrew Gill Participants: Justin Dawson, Mark Grebe, Ryan Scott, James Stanton, Jeffrey Rosenbluth, and Neil Sculthorpe Status: active Blank Canvas is a Haskell binding to the complete HTML5 Canvas API. Blank Canvas allows Haskell users to write, in Haskell, interactive images onto their web browsers. Blank Canvas gives the user a single full-window canvas, and provides many well-documented functions for rendering images. Out of the box, Blank Canvas is pac-man complete – it is a platform for simple graphics, classic video games, and building more powerful abstractions that use graphics. Blank Canvas was written in Spring 2012, as part of the preparation for a graduate-level functional programming class. In Fall 2012 and Fall 2013, we used Blank Canvas to teach Functional Reactive Programming. This was our first hint that the Blank Canvas library was faster than we expected, as we had hundreds of balls bouncing smoothly on the screen, much to the students’ delight. Blank Canvas has now been used by the students in four separate instances of our functional programming class. Students find it easy to understand, given the analog between the IO monad, and the remote Canvas monad, with student often choosing to use Blank Canvas for their end-of-semester project. To give two examples, one end-of-semester project was Omar Bari and Dain Vermaak’s Isometric Tile Game, that can be rotated in 3D in real-time; another project was Blankeroids, a playable asteroids clone, written by Mark Grebe, on top of Yampa and yampa-canvas. For more details, read the blank-canvas wiki. Further reading https://hackage.haskell.org/package/blank-canvas

https://github.com/ku-fpg/blank-canvas

https://github.com/ku-fpg/blank-canvas/wiki

PureScript is a small strongly typed programming language that compiles to efficient, readable JavaScript. The PureScript compiler is written in Haskell. The PureScript language features Haskell-like syntax, type classes, rank-n types, extensible records and extensible effects. PureScript features a comprehensive standard library, and a large number of other libraries and tools under development, covering data structures, algorithms, Javascript integration, web services, game development, testing, asynchronous programming, FRP, graphics, audio, UI implementation, and many other areas. It is easy to wrap existing Javascript functionality for use in PureScript, making PureScript a great way to get started with strongly-typed pure functional programming on the web. PureScript is currently used successfully in production in commercial code. The PureScript compiler was recently the focus of two successful Google Summer of Code projects, generously supported by the Haskell.org organization: The development of a searchable online database of PureScript code with type search and rendered documentation

The addition of an exhaustivity and redundancy checker for pattern matches. PureScript development is currently focussed on the following areas: Improving the performance of the compiler.

Improving error messages.

Enabling new backends (C++, Lua, Python, etc.)

The development of new PureScript libraries The PureScript compiler can be downloaded from purescript.org, or compiled from source from Hackage. Further reading https://github.com/purescript/purescript/

5.3 Haskell and Compiler Writing

5.3.1 MateVM Report by: Bernhard Urban Participants: Harald Steinlechner Status: looking for new contributors 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 processing 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 believe that Haskell is suitable to implement compiler technologies. However, we have to jump between “Haskell world” and “native code world”, due to the low-level nature of Just-In-Time compiler in a virtual machine. This poses some challenges when it comes to signal handling and other interesting 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 believe that Haskell is suitable to implement compiler technologies. However, we have to jump between “Haskell world” and “native code world”, due to the low-level nature of Just-In-Time compiler in a virtual machine. This poses some challenges when it comes to signal handling and other interesting 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 machine code emission. The software architecture enables easy addition of further optimization passes based 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). An interpreter can also be used to enable speculation during compilation and, if such a speculation fails, compiled code can deoptimize to the interpreter. Apart from that, features are still missing to comply as a JavaVM, most noteable are proper support for classloaders, floating point operations or threads. We would like to see a real base library such as GNU Classpath or the JDK running with MateVM some day. Other hot topics are Hoopl and Garbage Collection. We are looking for new contributors! 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

5.3.2 UUAG Report by: Atze Dijkstra Participants: ST Group of Utrecht University Status: stable, maintained 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.4), 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.52.1 (January 2015), is extensively tested, and is available on Hackage. There is also a Cabal plugin for easy use of AG files in Haskell projects. We recently implemented the following enhancements: Evaluation scheduling. We have done a project to improve the scheduling algorithms for AGs. The previously implemented algorithms for scheduling AG computations did 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 wanted to find and algorithm that can find this linear order, and thus lies in between the two existing approaches. We have created a backtracking algorithm for this which is currently implemented in the UUAG ( –aoag flag). Another approach to this scheduling problem that we implemented is the use of SAT-solvers. The scheduling problem can be reduced to a SAT-formula and efficiently solved by existing solvers. The advantage is that this opens up possibilities for the user to influence the resulting schedule, for example by providing a cost-function that should be minimized. We have also implemented this approach in the UUAG which uses Minisat as external SAT-solver ( –loag flag). We have recently worked on the following enhancements: Incremental evaluation. We have just finished a Ph.D. project that investigated incremental evaluation of AGs. The target of this work was 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. The project has lead to several publications, but the result has not yet been implemented into the UUAG compiler. Further reading http://www.cs.uu.nl/wiki/bin/view/HUT/AttributeGrammarSystem

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

6 Development Tools

6.1 Environments

6.1.1 Haskell IDE From FP Complete Report by: Natalia Muska Status: available, stable Since FP Complete announced the launch of FP Haskell Center (FPHC) in early September 2013, a lot of additions to the original IDE have been added and the pricing structure has changed dramatically. The new features and the pricing modifications are a direct result of community feedback. The changes were gradually rolled out over the past year. As of October 1, 2014, all users of FPHC who are using it for non-commercial projects have free access under the new Open Publish model. This means that Open Publish accounts will automatically publish all projects on the FPHC site with each commit, similar to Github. This move is meant to make FPHC more valuable, and increase support for users sharing their work with the community. There are still paid subscriptions available for Commercial projects. This is a current list of features included with the free version of FPHC: Create and Edit Haskell Projects,

Open Projects from Git, FPHC, or Web

Continuous Error and Type Information

Hoogle and Haddock Integration

Easy to use build system

Vetted Stable Libraries

Easy to Understand Error Messages

No setup or install

Free Community Support

Push Projects to Git and GitHub

Emacs Integration

Shared Team Accounts

Support for Sub Projects

Multiple Repository Projects

Deploy to FP Application Servers

Large Project and Megarepos Support (new)

Subscriptions include continuous refresh releases on new features, updates, bug fixes and free community support Over the past year the feedback and activity on FPHC has been very positive. To ensure FPHC is meeting the demands of the Haskell community, FP complete is constantly seeking feedback and suggestions from users and the Haskell community. Further reading Visit www.fpcomplete.com for more information.

ghc-mod is both a backend program for enhancing editors and other kinds of development environments with support for Haskell, and an Emacs package providing the user facing functionality, internally called ghc for historical reasons. Other people have also developed numerous front ends for Vim and there also exist some for Atom and a few other proprietary editors. This summer’s two month ghc-mod hacking session was mostly spent (finally) getting a release supporting GHC 7.10 out the door as well as fixing bugs and adding full support for the Stack build tool. Since the last report the haskell-ide-engine project has seen the light of day. There we are planning to adopt ghc-mod as a core component to use its environment abstraction. The haskell-ide-engine project itself is aiming to be the central component of a unified Haskell Tooling landscape. In the light of this ghc-mod ’s mission statement remains the same but in the future it will be but one, important, component in a larger ecosystem of Haskell Tools. We are looking forward to haskell-ide-engine making the Haskell Tooling landscape a lot less fragmented. However until this project produces meaningful results life goes on and ghc-mod ’s ecosystem needs to be maintained. Right now ghc-mod has only one core developer and a handful of occasional contributors. If you want to help make Haskell development even more fun come and join us! Further reading https://github.com/kazu-yamamoto/ghc-mod

6.1.3 haskell-ide-engine, a project for unifying IDE functionality Report by: Chris Allen Participants: Alan Zimmerman, Michael Sloan, Gracjan Polak, Daniel Gröber, others welcome Status: Open source, just beginning haskell-ide is a backend for driving the sort of features programmers expect out of IDE environments. Perhaps soon to be called haskell-ide-engine, haskell-ide is a project to unify tooling efforts into something different text editors, and indeed IDEs as well, could use to avoid duplication of effort. Features like type errors, linting, refactoring, and reformatting code are planned. People who are familiar with a particular part of the chain can focus their efforts there, knowing that the other parts will be handled by other components of the backend. Inspiration is being taken from the work the Idris community has done toward an interactive editing environment as well. This is a deliberately broad scope, the initial versions will be very limited at first. The sooner we can get started the sooner we will have something concrete to criticise and improve. Help is very much needed and wanted so if this is a problem that interests you, please pitch in! This is not a project just for a small inner circle. Anyone who wants to will be added to the project on github, address your request to @alanz or @hvr. Further reading https://github.com/haskell/haskell-ide-engine

https://mail.haskell.org/pipermail/haskell-cafe/2015-October/121875.html

https://www.fpcomplete.com/blog/2015/10/new-haskell-ide-repo

https://www.reddit.com/r/haskell/comments/3pt560/ann_haskellide_project/

https://www.reddit.com/r/haskell/comments/3qbgmo/fp_complete_the_new_haskellide_repo/

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, a Google Group called https://groups.google.com/forum/#!forum/hare and an IRC channel on freenode called #haskell-refactorer. IRC is the preferred contact method. Current version of HaRe supports 7.10.2 and work is continuing to support GHC version 8.x forward. The new version makes use of ghc-exactprint library, which only has GHC support from GHC 7.10.2 onwards. Development on the core HaRe is focusing is on making sure that deficiencies identified in the API Annotations in GHC used by ghc-exactprint are removed in time for GHC 8.0.1, so that the identity refactoring can cover more of the corner cases. There is also a new haskell-ide project which will allow HaRe to operate as a plugin and will ease its integration into multiple IDEs. Recent developments The current version is 8.2, which supports GHC 7.10.2 only, and was released in October 2015.

Matthew Pickering has been deeply involved in the ghc-exactprint development, and successfully completed his Google Summer of Code project which involved bringing it up to standard, which has helped tremendously for HaRe .

development, and successfully completed his Google Summer of Code project which involved bringing it up to standard, which has helped tremendously for . There is plenty to do, so anyone who has an interest is welcome to fork the repo and get stuck in.

Stephen Adams is continuing 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/RefactoringTools/HaRe

https://github.com/alanz/ghc-exactprint

http://mpickering.github.io/gsoc2015.html

https://github.com/haskell/haskell-ide

ghc-exactprint aims to be a low-level foundation for refactoring tools. Unlike most refactoring tools, it works directly with the GHC API which means that it can understand any legal Haskell source file. The program works in two phases. The first phase takes the output from the parser and converts all absolute source positions into relative source positions. This means that it is much easier to manipulate the AST as you do not have to worry about updating irrelevant parts of your program. The second phase performs the reverse process, it converts relative source positions back into absolute positions before printing the source file. The entire library is based around a free monad which keeps track of which annotations should be where. Each process is then a different interpretation of this structure. In theory these two processes should be entirely separate but at the moment they are not entirely decoupled due to shortcomings we are addressing in GHC 8.0. In order to verify our foundations, the program has been run on every source file on Hackage. This testing highlighted a number of bugs which have been fixed for GHC 7.10.2. Apart from a few outstanding issues with very rare cases, we can now confidently say that ghc-exactprint is capable of processing any Haskell source file. Over the last few months Alan Zimmerman has integrated ghc-exactprint into HaRe(→6.1.4) whilst Matthew Pickering participated in Google Summer of Code to provide integration with HLint . Both of these proceeded smoothly, and are now working. ghc-exactprint has also been used for a proof of concept tool to migrate code forward for AMP and MRP, see link below. Alan Zimmerman also presented ghc-exactprint at HIW2015, and Matthew Pickering at SkillsMatter in October. Links to the respective videos are provided below. Further reading https://github.com/alanz/ghc-exactprint

https://github.com/hvr/Hs2010To201x

https://www.youtube.com/watch?v=U5_9mfQAUBo - HIW2015

https://skillsmatter.com/skillscasts/6539-a-new-foundation-for-refactoring-ghc-exactprint - Skills Matter, (free) registration required

6.1.6 IHaskell: Haskell for Interactive Computing Report by: Andrew Gibiansky Status: stable IHaskell is an interactive interface for Haskell development. 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 yields in-browser data visualizations, while integration with Aeson’s JSON yields a syntax-highlighted JSON output for complex data structures. Implementation-wise, IHaskell is a language kernel backend for the Jupyter project, a language-agnostic protocol and set of frontends by which interactive code environments such as REPLs and notebooks can communicate with a language evaluator backend. IHaskell also provides a generic library for writing Jupyter kernels, which has been used successfully in the ICryptol project. 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 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. Further reading https://github.com/gibiansky/IHaskell

6.1.7 Haskell for Mac Report by: Manuel M. T. Chakravarty Status: Available &actively developed Haskell for Mac is an easy-to-use integrated programming environment for Haskell on OS X. It includes its own Haskell distribution and requires no further set up. It features interactive Haskell playgrounds to explore and experiment with code. Playground code is not only type-checked, but also executed while you type, which leads to a fast turn around during debugging or experimenting with new code. Integrated environment. Haskell for Mac integrates everything needed to start writing Haskell code, including an editor with syntax highlighting and customisable themes. (Alternatively, users can also configure an external editor.) Haskell for Mac creates Haskell projects based on standard Cabal specifications for compatibility with the rest of the Haskell ecosystem. It includes the Glasgow Haskell Compiler (GHC) and over 200 of the most popular packages. Type directed development. Haskell for Mac uses GHC’s support for deferred type errors so that you can still execute playground code in the face of type errors. This is convenient during refactoring to test changes, while some code still hasn’t been adapted to new signatures. Moreover, you can use type holes to stub out missing pieces of code, while still being able to run code. The system will also report the types expected for holes and the types of the available bindings. Interactive graphics. Haskell for Mac includes special support for the Rasterific, Diagrams, and Chart libraries. Graphical results are immediately displayed in the playground. They are also live and change as you modify the program code. Moreover, Haskell for Mac includes a binding to the main parts of Apple’s 2D animation and games framework SpriteKit. The Haskell binding to SpriteKit is purely functional using an immutable representation of the scene graph and pure transformation functions. SpriteKit scenes are rendered as interactive popover windows in the Haskell for Mac playground, where they react to keyboard, mouse, and trackpad events. Haskell for Mac is available for purchase from the Mac App Store. Just search for "Haskell", or visit our website for a direct link. We are always available for questions or feedback at support@haskellformac.com. The current version of Haskell for Mac is based on GHC 7.8.4 and LTS Haskell 2.20. We are currently preparing an update to GHC 7.10 and LTS Haskell 3. We are working on several extensions to Haskell for Mac, which we will announce once we have concrete release dates. Further reading The Haskell for Mac website: http://haskellformac.com

6.1.8 Haskino Report by: Mark Grebe Participants: Andrew Gill Status: active Haskino is a Haskell development environment for programming the Arduino microcontroller boards in a high level functional language instead of the low level C language normally used. Haskino presents two complimentary ways of developing programs for the Arduino. The first method allows programming of an Arduino tethered to a host computer through a serial connection. This work started with Levent Erkok’s hArduino package. To this we have added our strong Remote Monad concepts, which provide a more efficient method of communication with the board. We have also replaced the Firmata serial communication protocol and firmware with a new protocol and firmware which also allow for more efficient communication, and are expandable to meet the needs of our second programming method. The second method of programming the Arduino uses a deep embedding to out-source entire groups of commands and control-flow idioms. These programs may then be stored in EEPROM on the board, and executed from startup, with no connection to the host computer required. A Haskell programmer can start program development with the first method, which allows for convenient prototyping and debugging. The program can then be moved to the second method, with the entire computation being performed on the Arduino, and not requiring the host computer. The development has been active over the past 6 months and there is a paper accepted for publication at PADL 2016. Further reading https://github.com/ku-fpg/haskino

https://github.com/ku-fpg/wiki

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 was Darcs 2.10 (April 2015). This release includes the new darcs rebase command (for merging and amending patches that would be hard to do with patch theory alone), numerous optimisations and performance improvements, a darcs convert command for switching to and from Git, as well as general improvements to the user interface. In more recent news, we have gotten back into what we hope to be a habit of regular Darcs hacking sprints, with a recent one in Paris this September and in Seville this upcoming January. We also have a new maintainer, Guillaume Hoffmann. Guillaume has been with the project for five years now and has been working on bringing new developers into the project and making links between Darcs and other communities. SFC and donationsDarcs 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/Releases/2.10

6.2.2 cab — A Maintenance Command of Haskell Cabal Packages Report by: Kazu Yamamoto Status: open source, actively developed 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 GHC 7.10. Further reading http://www.mew.org/~kazu/proj/cab/en/

6.3 Interfacing to other Languages

6.3.1 java-bridge Report by: Julian Fleischer Status: active development The Java Bridge is a library for interfacing the Java Virtual Machine with Haskell code and vice versa. It comes with a rich DSL for discovering and invoking Java methods and allows to set up callbacks into the Haskell runtime. If exported via the FFI it is also possible to use Haskell libraries from within the JVM natively. The package also offers a bindings generator which translates the API of a Java class or package into a Haskell API. Using the bindings generator it is possible to generate a Haskell module with a clean Haskell API that invokes Java behind the scenes. Typical conversions, for example byte arrays to lists or Java maps to lists of key value pairs, are taken care of. The generated bindings and predefined conversions are extensible by defining appropriate type class instances accordingly. While the documentation for the bindings generator still needs improvement, the overall library is in a quite usable state. The java bridge is published under the MIT license and available via hackage as java-bridge . Further reading If you want to know more about the inner workings: The Java Bridge has been created as part of a bachelor thesis which you can access at http://page.mi.fu-berlin.de/scravy/bridging-the-gap-between-haskell-and-java.pdf.

6.3.2 fficxx Report by: Ian-Woo Kim Participants: Ryan Feng Status: Actively Developing fficxx (“eff fix”) is an automatic haskell Foreign Function Interface (FFI) generator to C++. While haskell has a well-specified standard for C FFI, interfacing C++ library to haskell is notoriously hard. The goal of fficxx is to ease making haskell-C++ binding and to provide relatively nice mapping between two completely different programming paradigms. To make a C++ binding, one write a haskell model of the C++ public interfaces, and then fficxx automatically generates necessary boilerplate codes in several levels: C++-C shims, C-haskell FFI, low level haskell type representation for C++ class/object and high level haskell type and typeclass representation and some casting functions. The generated codes are organized into proper haskell modules to minimize name space collision and packaged up as cabal packages. The tool is designed to adapt different configurations and unique needs, such as splitting bindings into multiple cabal packages and renaming classes and functions to resolve some obstacles that are originated from naming collision, which is quite inevitable in making an FFI library. The information of a C++ library can be written in terms of simple haskell expressions, aiming at good usability for ordinary haskell users. For example, if we have a C++ library which has the following interface: class A {

public:

A();

virtual void Foo();

};

class B : public A {

public:

B();

virtual void Bar();

};

one provide the model in terms of haskell data type defined in fficxx library: a = myclass "A" [] mempty Nothing

[ Constructor [] Nothing

, Virtual void_ "Foo" [ ] Nothing ]

b = myclass "B" [a] mempty Nothing

[ Constructor [] Nothing

, Virtual void_ "Bar" [] Nothing ]

one provide the model in terms of haskell data type defined in fficxx library: One of the projects that successfully uses fficxx is HROOT which is a haskell binding to the ROOT library. ROOT is a big C++ histogramming and statistical analysis framework. Due to fficxx, the HROOT package faithfully reflects the ROOT C++ class hierarchy, and the user from C++ can use the package relatively easily. fficxx is available on hackage and being developed on the author’s github (http://github.com/wavewave/fficxx). In 2013, with Ryan Feng, we tried to make fficxx more modernized with more transparent support of various C/C++ data types, including consistent multiple pointer/reference operations and function pointers. fficxx is still being in progress in incorporating the new pointer operations. C++ template support is now planned. Further reading http://ianwookim.org/fficxx

6.4 Deployment

6.4.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. Looking forward We would like to encourage people considering contributing to take a look at the bug tracker on github, take part in discussions on tickets and pull requests, or submit their own. The bug tracker is reasonably well maintained and it should be relatively clear to new contributors what is in need of attention and which tasks are considered relatively easy. For more in-depth discussion there is also the cabal-devel mailing list. Further reading Cabal homepage: http://www.haskell.org/cabal

Hackage package collection: http://hackage.haskell.org/

Bug tracker: https://github.com/haskell/cabal/

6.4.2 Stackage: the Library Dependency Solution Report by: Natalia Muska Status: new Stackage began in November 2012 with the mission of making it possible to build stable, vetted sets of packages. The overall goal was to make the Cabal experience better. Two years into the project, a lot of progress has been made and now it includes both Stackage and the Stackage Server. To date, there are over 700 packages available in Stackage. The official site is www.stackage.org. Stackage Update: Stackage is an infrastructure to create stable builds of complete package sets referred to as "snapshots." Stackage provides users with the assurance that their packages will always build, will actually compile, all tests suites pass, and all will work across three GHC versions (7.8, 7.6, and 7.4). Users of a snapshot verified by Stackage can expect all packages to install the first time. Each snapshot is given a unique hash which is a digest of that snapshot’s package set. Snapshots don’t change. Once a hash is provided, it refers only to that snapshot. So if a user writes a project using snapshot aba1b51af, and in two months switches to another machine and builds their project with aba1b51af, it will succeed. For package authors, Stackage gives them the valuable knowledge that their package builds and tests successfully across the current, stable and old GHC versions. Library authors have guarantees that users of Stackage can easily use their library and can do so on a reasonable number of GHCs. Authors are also informed when a newly uploaded package breaks theirs, meaning it’s time to update the package for it to be included in the latest snapshot. Recently Stackage added some additional features including Haddock documentation and cabal.config files. By including Haddock documentation in Stackage all new exclusive snapshots have Haddock links allowing users to view documentation of all packages included in the snapshot. This means users can generally view everything in one place, on one high-availability service. By creating a cabal.config link on snapshot pages, Stackage users don’t have to change their remote-repo field. Stackage Server: Before Stackage Server, use of Stackage was limited to either manually downloading a project and building it all locally, or by using FP Haskell Center. With Stackage Server, users are able to go to the server web site and pick a snapshot. On the build is a simple copy/paste line to use as a Cabal repo, to replace the users existing remote-repo line. When a new package is released and has been properly updated, users can go to the Stackage home page and get the latest snapshot and update their repo. The Stackage server also supports the uploading of custom snapshots, this allows a company, a Linux distribution, an organization, a university, or just as a general hacker who wants to keep all their projects under one package set, to maintain their own custom series of snapshots, and also make it available to other people. Then the burden will be on those users to make sure it builds, rather than the recommended and Stackage maintained snapshots. If you’ve written some code that you’re actively maintaining, don’t hesitate to get it in Stackage. You’ll be widening the potential audience of users for your code by getting your package into Stackage, and you’ll get some helpful feedback from the automated builds so that users can more reliably build your code.

6.4.3 Haskell Cloud Report by: Gideon Sireling Haskell Cloud is an OpenShift cartridge for deploying Haskell on Red Hat’s open source PaaS cloud. It includes GHC 7.8, cabal-install, Gold linker, and a choice of pre-installed frameworks - a full list can be viewed on the Wiki. Using a Haskell Cloud cartridge, existing Haskell projects can be uploaded, build, and run from the cloud with minimal changes. Ongoing development is focused on OpenShift’s upcoming Docker release and GHC 7.10. Further reading https://bitbucket.org/accursoft/haskell-cloud

http://www.haskell.org/haskellwiki/Web/Cloud#OpenShift

https://blog.openshift.com/functional-programming-in-the-cloud-how-to-run-haskell-on-openshift/

6.5 Others

6.5.1 ghc-heap-view Report by: Joachim Breitner Participants: Dennis Felsing Status: active development The library ghc-heap-view provides means to inspect the GHC’s heap and analyze the actual layout of Haskell objects in memory. This allows you to investigate memory consumption, sharing and lazy evaluation. This means that the actual layout of Haskell objects in memory can be analyzed. You can investigate sharing as well as lazy evaluation using ghc-heap-view. The package also provides the GHCi command :printHeap , which is similar to the debuggers’ :print command but is able to show more closures and their sharing behaviour: > let x = cycle [True, False]

> :printHeap x

_bco

> head x

True

> :printHeap x

let x1 = True : _thunk x1 [False]

in x1

> take 3 x

[True,False,True]

> :printHeap x

let x1 = True : False : x1

in x1

The graphical tool ghc-vis ?? builds on ghc-heap-view. Since version 0.5.3, ghc-heap-view also supports GHC 7.8. Further reading http://www.joachim-breitner.de/blog/archives/548-ghc-heap-view-Complete-referential-opacity.html

http://www.joachim-breitner.de/blog/archives/580-GHCi-integration-for-GHC.HeapView.html

http://www.joachim-breitner.de/blog/archives/590-Evaluation-State-Assertions-in-Haskell.html

Hat is a source-level tracer for Haskell. Hat gives access to detailed, otherwise invisible information about a computation. Hat helps locating errors in programs. Furthermore, it is useful for understanding how a (correct) program works, especially for teaching and program maintenance. Hat is not a time or space profiler. Hat can be used for programs that terminate normally, that terminate with an error message or that terminate when interrupted by the programmer. You trace a program with Hat by following these steps: With hat-trans translate all the source modules of your Haskell program into tracing versions. Compile and link (including the Hat library) these tracing versions with ghc as normal. Run the program. It does exactly the same as the original program except for additionally writing a trace to file. After the program has terminated, view the trace with a tool. Hat comes with several tools for selectively viewing fragments of the trace in different ways: hat-observe for Hood-like observations, hat-trail for exploring a computation backwards, hat-explore for freely stepping through a computation, hat-detect for algorithmic debugging, … Hat is distributed as a package on Hackage that contains all Hat tools and tracing versions of standard libraries. Hat works with the Glasgow Haskell compiler for Haskell programs that are written in Haskell 98 plus a few language extensions such as multi-parameter type classes and functional dependencies. Note that all modules of a traced program have to be transformed, including trusted libraries (transformed in trusted mode). For portability all viewing tools have a textual interface; however, many tools require an ANSI terminal and thus run on Unix / Linux / OS X, but not on Windows. Further reading Initial website: http://projects.haskell.org/hat

H