- Haskell-Cafe - Haskell.org

Announce: Probablistic programming in Haskell with bali-phy
by Benjamin Redelings 18 Jun '17

18 Jun '17

Hi, I'm working on a project to implement support for probabilistic programming with models written as Haskell programs. This is similar to Bayesian graphical models (e.g. BUGS, JAGS) and to full probabilistic programming systems like Church / Venture. http://www.bali-phy.org/models.php This project is not very mature, but it is used as the core of the MCMC software mentioned above, which is relatively mature. Probabilistic programs are written using the probability monad. I've implemented a Haskell interpreter in C++ that records execution traces of the Haskell programs. These execution traces depend on some number of (random) variables, and when one of the variables is changed (during MCMC), the parts of the execution trace that depend on the changed variables are invalidated and recomputed. This saves work by not recomputing the probability of the new state from scratch. I can provide DOT graphs of the execution traces if anyone is interested. The problem domain I've been focusing on is evolution of DNA sequences on binary trees. You can see some of the code for that problem domain here: https://github.com/bredelings/BAli-Phy/blob/master/modules/ The code for the interpreter is here: https://github.com/bredelings/BAli-Phy/blob/master/src/computation/ -BenRI

2 3

Issue 59 :: Haskell Weekly
by Taylor Fausak 15 Jun '17

15 Jun '17

\ Haskell Weekly \/\/ Issue 59 <https://haskellweekly.news/issues/59.html> Welcome to another issue of Haskell Weekly! Haskell is a purely functional programming language that focuses on robustness, concision, and correctness. This is a weekly summary of what's going on in its community. ## Featured - Haskell on Android and iOS <http://keera.co.uk/blog/2017/06/01/haskell-android-ios/> > With our framework, writing professional Haskell apps and games becomes a reality. In minutes one can have the complete toolchain and see the first app running on a phone or published on the online store. If you weren't considering using Haskell yet, we hope you soon change your mind. - Translating a C++ parser to Haskell <http://www.haskellforall.com/2017/06/translating-c-parser-to-haskell.html> > Recently I translated Nix's derivation parser to Haskell and I thought this would make an instructive example for how C++ idioms map to Haskell idioms. This post targets people who understand Haskell's basic syntax but perhaps have difficulty translating imperative style to a functional style. - The `ReaderT` design pattern <https://www.fpcomplete.com/blog/2017/06/readert-design-pattern> > What many languages address via patterns, in Haskell we address via language features (like built-in immutability, lambdas, laziness, etc.). However, I believe there is still room for some high-level guidance on structuring programs, which I'll loosely refer to as a Haskell design pattern. - Front Row is hiring a senior backend Haskell engineer (ad) <https://frontrow.workable.com/j/463B843754> > Come change how 6.5+ million K-12 US students learn Math, Language Arts, Social Studies and more. Use data, advanced type systems, great product design and deep pedagogy to change lives. - 10 things Idris improved over Haskell <https://deque.blog/2017/06/14/10-things-idris-improved-over-haskell/> > This post describes some of the pleasant surprises you get trying out Idris, coming from the Haskell world. These pleasant surprises have nothing to do with the dependent typing features. They are simple yet impacting modifications, which improve the developer experience substantially. - Migrating text metrics to pure Haskell <https://markkarpov.com/post/migrating-text-metrics.html> > text-metrics-0.3.0 is written in pure Haskell, almost as fast as the previous versions (especially for not very long inputs), and is more correct (we handle characters represented as two `Word16` values properly). - ZuriHac 2017 recap <https://jship.github.io/posts/2017-06-11-zurihac-recap.html> > This was my first time attending ZuriHac and it was too much fun --- will definitely be back next year! Big thanks to Jasper Van der Jeugt, Simon Meier, and all of the HSR folks that made the event happen. Props to the Haskell community too for being friendly and inviting. - Haddock markup quick reference <https://github.com/aisamanra/haddock-cheatsheet/blob/c3485d33e6bb42beb41c97…> > This page is a single-page quick reference for the markup used in GHC's Haddock documentation format. It doesn't list all the details of the format, just the basic markup, so for the vagaries and edge-cases of the syntax, it would be helpful to consult the Haddock user guide. - Haskell Summer of Code <https://jaredweakly.com/blog/haskell-summer-of-code/> > The performance tests do two things: first, they make sure that when people change the compiler, they don't accidentally make it slower; secondly, they make sure that when people change the compiler, they don't accidentally make the generated code less efficient. - Use hpack <https://e.xtendo.org/haskell/hpack> > One of the remaining problems is that the `project.cabal` file is in a custom format. Custom formats are generally not good because you can't leverage the existing tools and free-ride other people's work. - Haskell taketh away: Limiting side effects for parallel programming <https://www.youtube.com/watch?v=lC5UWG5N8oY> > In designing parallel programming abstractions, taking away user capabilities is as important as granting them. In this talk, I'll explain the role of this idea in several different parallel programming libraries for Haskell, C++, and other languages --- spanning from shared memory to big data. ## Package of the week This week's package of the week is generic-lens, a library that exposes generic data structure operations as lenses. <https://hackage.haskell.org/package/generic-lens-0.2.0.0> ## In brief - Binary instances for GADTs (or: RTTI in Haskell) <https://www.well-typed.com/blog/2017/06/rtti/> - Data structures are antithetical to functional programming <http://degoes.net/articles/kill-data> - Drive-by Haskell contributions <http://ndmitchell.com/downloads/slides-drive-by_haskell_contributions-09_ju…> - On friendly contributing policies <https://ro-che.info/articles/2017-06-12-friendly-contributing-policies> - Taking a close look at lenses <https://mmhaskell.com/blog/2017/6/12/taking-a-close-look-at-lenses> - Teaching Haskell for understanding <https://docs.google.com/presentation/d/1_I5mYXivG5NbOHnICld_Xo41uOyAT57Yade…> - The Haskell Cast episode 14: Richard Eisenberg on dependent types <http://www.haskellcast.com/episode/014-richard-eisenberg-on-dependent-types…>

1 0

Error-containing Maybes
by Ivan Lazar Miljenovic 15 Jun '17

15 Jun '17

The Maybe type is often (almost always?) used to indicate that a computation may fail; specifically, `Maybe a` typically indicates that it may not be possible to always produce a value of type `a`. However, there are times when the inverse of this is desirable (usually within a monadic/side-effectful context): if Nothing is returned then the computation was a success; otherwise, an error message is returned. Whilst this usage definitely fits the types, it breaks the mould of how we think/use Maybe in most cases and may at times cause confusion. As such, it may be advisable (and I know I've done this at least once) to define a `data Result e = Error e | Success` data type to model this behaviour. Is this a typical enough requirement that would make it worth adding such a datatype to base (despite my usual aversion to piling more things in there) or having a library up on Hackage just for this very simplistic type? (Another option would be to use `Either error ()`, which could be lifted better into an ExceptT result, albeit with the additional useless parameter/value in there.) -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

3 3

Re: [Haskell-cafe] Announce: Probablistic programming in Haskell with bali-phy
by Olaf Klinke 15 Jun '17

15 Jun '17

Benjamin, I'm also excited to see more probabilistic programming in Haskell. Adding to Sergiu's questions I'd like to know why you chose to implement a new interpreter instead of making an embedded domain-specific language. Are there C++ libraries that were convenient to use? As theorist I'm curious whether you have a denotational semantics in mind. Can you decribe the building blocks of your language? The examples show primitives for known families of distributions (e.g. beta). Then there is Observe, which seems to compute conditional distributions. What else is there beyond ordinary Haskell? Cheers, Olaf

1 0

use of models in proving program properties
by Ben Franksen 13 Jun '17

13 Jun '17

This is something that has left me puzzled for years. My understanding is that a model is a concrete realization of an abstract structure in terms of some other mathematical structure, such that all the laws from the first are satisfied in the latter. A simple example might be the abstract (algebraic) structure "group" and a concrete realization e.g. the integers with addition. Finding models for abstract theories is certainly useful, for instance it shows that the theory is actually 'inhabited'; it may also shed light on the theory and give us ideas about new theorems that might generalize to the abstract setting. However, nobody would claim that from a theorem about integers I can deduce one for abstract groups in general. But exactly this kind of reasoning appears to be valid when proving things about e.g. the polymorphic lambda calculus (aka System F). For instance, in the famous "free theorems" paper by Wadler, the free theorems appear as a consequence of modeling types in system F as relations (this is most probably oversimplified, i can't remember the details but I think they are not important here). The question is: How can that imply anything about system F itself? Wouldn't it be necessary to prove that these free theorems hold for /all/ models of System F, not just one particular? Besides, if such proofs using a suitable model are really valid, why does it seem to be impossible to 'translate the proof back' from the model to the original system and thus arrive at a direct proof? I am sure there is something wrong with my understanding of these things but I can't figure out what. Cheers Ben

2 2

1st CfP: IFL 2017 (29th Symposium on Implementation and Application of Functional Languages)
by publicityifl＠gmail.com 12 Jun '17

12 Jun '17

<div dir="ltr">Hello, Please, find below the first call for papers for IFL 2017. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL --- IFL 2017 - CALL FOR PAPERS ========================== 29th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES ======================================================================== University of Bristol, UK In cooperation with ACM SIGPLAN Wednesday 30 August - Friday 1 September, 2017 <a href="http://iflconference.org/">http://iflconference.org/</a> Scope ----- The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2017 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Peer-review ----------- Following the IFL tradition, IFL 2017 will use a post-symposium review process to produce the formal proceedings. All participants of IFL 2017 are invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: <a href="http://www.sigplan.org/Resources/Policies/Republication">http://www.sigplan.org/Resources/Policies/Republication</a> The submissions will be screened by the program committee chair to make sure they are within the scope of IFL, and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. Hence, publications that appear only in the draft proceedings are not subject to the ACM SIGPLAN republication policy. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal review process. From the revised submissions, the program committee will select papers for the formal proceedings considering their correctness, novelty, originality, relevance, significance, and clarity. The formal proceedings will appear in the International Conference Proceedings Series of the ACM Digital Library. Important dates --------------- Mon 31 July 2017 : Submission deadline draft papers Wed 2 August 2017 : Notification of acceptance for presentation Fri 4 August 2017 : Early registration deadline Fri 11 August 2017 : Late registration deadline Mon 21 August 2017 : Submission deadline for pre-symposium proceedings Wed 30 August 2017 - Fri 1 September 2017 : IFL Symposium Mon 4 December 2017 : Submission deadline for post-symposium proceedings Wed 31 January 2018 : Notification of acceptance for post-symposium proceedings Mon 12 March 2018 : Camera-ready version for post-symposium proceedings Submission details ------------------ Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English. Papers must use the new ACM two columns conference format, which can be found at: <a href="http://www.acm.org/publications/proceedings-template">http://www.acm.org/publications/proceedings-template</a> For the pre-symposium proceedings we adopt a 'weak' page limit of 12 pages. For the post-symposium proceedings the page limit of 12 pages is firm. Authors submit through EasyChair: <a href="https://easychair.org/conferences/?conf=ifl2017">https://easychair.org/conferences/?conf=ifl2017</a> Topics ------ IFL welcomes submissions describing practical and theoretical work as well as submissions describing applications and tools in the context of functional programming. If you are not sure whether your work is appropriate for IFL 2017, please contact the PC chair at <a href="mailto:nicolas.wu@bristol.ac.uk">nicolas.wu(a)bristol.ac.uk</a>. Topics of interest include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications Peter Landin Prize ------------------ The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. Programme committee ------------------- Chair: Nicolas Wu, University of Bristol, UK - Kenichi Asai, Ochanomizu University, Japan - Sandrine Blazy, University of Rennes 1, France - Carlos Camarao, Universidade Federal de Minas Gerais, Brazil - Stephen Dolan, University of Cambridge, UK - Jurriaan Hage, Utrecht University, Netherlands - Yukiyoshi Kameyama, University of Tsukuba, Japan - Benjamin Lerner, Brown University, USA - Bas Lijnse, Radboud University, Netherlands - Garrett Morris, University of Kansas, USA - Miguel Pagano, Universidad Nacional de C√≥rdoba, Argentina - Tomas Petricek, Alan Turing Institute, UK - Maciej Pir√≥g, University of Wroc≈Çaw, Poland - Exequiel Rivas, Universidad Nacional de Rosario, Argentina - Neil Sculthorpe, Nottingham Trent University, UK - Melinda T√≥th, E√∂tv√∂s Lor√°nd University, Hungary - Phil Trinder, Glasgow University, UK - Kanae Tsushima, National Institute of Informatics, Japan - Marcos Viera, Universidad de la Republica, Uruguay - Meng Wang, University of Kent, UK Venue ----- The IFL 2017 will be held in association with the Department of Computer Science, University of Bristol, UK. Bristol is located in South West England, and can be easily reached from Bristol Airport. See the website for more information on the venue. </div>  <a style='display: block; margin: 32px 0 40px 0; padding: 10px; font-size: 1em; text-align: center; border: 0; border-top: 1px solid gray; ' href='https://goo.gl/2ksdRv'>powered by GSM. Free mail merge and email marketing software for Gmail.</a>

1 0

Re: [Haskell-cafe] ANNOUNCE: streaming-conduit
by Olaf Klinke 12 Jun '17

12 Jun '17

Dear Ivan, I'm confused. The package documentation states that the typical problem to avoid is extracting a long list from IO, which is bound to allocate too much memory. However, if I do preprocess :: IO [a] preprocess = fmap (map (parse :: String -> a) . lines) $ readFile filename then this may create a huge pile of thunks if the rest of the program is not written in a streaming style. But if done right, lazy IO will make sure only the necessary part of the list is kept im memory. For example, a strict function like postprocess :: [a] -> IO () postprocess = mapM (print . f) with some strict f would fit the bill. Did I get the concept of lazy IO wrong? What is the operational semantics of the following fragment? x:xs <- someIOaction :: IO [a] Control.DeepSeq.force x I used to think that xs is now a thunk which, when evalated further, may trigger more (read) IO actions. Hence, would behave as if someIOaction was one of your Streams. I do acknowledge, though, that the style above is easy to go wrong [*], whereas explicitly wrapping each list element in its own monadic action makes the intentions more verbose. Cheers, Olaf [*] If someIOaction needs to touch every list element in order to ensure the result has the shape _:_ then we will indeed have a huge list of thunks.

2 1

Bug in GHC or cabal-install?
by Henk-Jan van Tuyl 12 Jun '17

12 Jun '17

L.S., I am trying the prerelease of GHC, version 8.2.0.20170507 I adapted wxHaskell to the new packages that come with the new GHC and it compiles now, but only the first time. If I compile it a second time, even if nothing has changed, the information from the custom-setup section of the wxc.cabal file seems to be forgotten. This section looks like this: custom-setup setup-depends: base, Cabal < 2, containers, bytestring, split, process, directory, filepath (I am using cabal-install 1.24.0.2) Output from the second time I try to install wxHaskell: > cabal install --force-reinstalls --reinstall wxdirect wxc wxcore wx [1 of 1] Compiling Main ( X:\Temp\wxHaskell\wxcore\dist\setup\setup.hs, X:\Temp\wxHaskell\wxcore\dist\setup\Main.o ) Linking X:\Temp\wxHaskell\wxcore\dist\setup\setup.exe ... [1 of 1] Compiling Main ( X:\Temp\wxHaskell\wxc\dist\setup\setup.hs, X:\Temp\wxHaskell\wxc\dist\setup\Main.o ) X:\Temp\wxHaskell\wxc\dist\setup\setup.hs:505:61: error: Variable not in scope: versionBranch :: Version -> [a0] | 505 | full_ver = (concat . intersperse "." . map show . versionBranch) ver | ^^^^^^^^^^^^^ This error message indicates that the wrong version of Cabal (2.0) is used to compile the wxcore setup.hs It looks like a cabal-install bug, but this does not happen when I use GHC 8.0.2; should I write a GHC bug ticket? Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://foldingathome.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

3 6

[ANN] Budapest Haskell Hackathon 2017, 29-30th July 2017
by Daniel Berecz 11 Jun '17

11 Jun '17

Hi everybody, I'm happy to announce that our local user group will hold a Haskell Hackathon in Budapest this year (this will be the second)! We will hold it from the 29th to the 30th of July (Saturday & Sunday). You can find out more on the following link: https://wiki.haskell.org/Budapest_Hackathon_2017 We will reguraly update the site with new information. If you decide to come, please fill out the following Google Form: https://goo.gl/forms/QjTNdXTD1aEOMEQU2 If you have a project, demo, or talk that you want to bring to the event please contact us, and we can talk about the details. You can find our contact info the events wiki site, or you can just contact me directly. The event will be open to people of all experience levels, from beginners to gurus. The only requisite is that you’re interested in the Haskell language, and want to hang out with us, and have a good time! Greetings from Daniel, and the other BP-HUG organizers.

1 0

Last call for presentations: CUFP 2017, September 7-9, Oxford, UK
by Jasper Van der Jeugt 10 Jun '17

10 Jun '17

The deadline for CUFP presentations is this friday, the 9th of June. This CFP and the form for submitting presentations proposals can be found at: http://cufp.org/2017/call-for-presentations.html ------------------------------------------------------------------------ 2017 Call for Presentations Workshop for Commercial Users of Functional Programming 2017 Sponsored by SIGPLAN CUFP 2017 Co-located with ICFP 2017 Oxford, UK September 7-9 Talk Proposal Submission Deadline: 9 June 2017 The annual CUFP event is a place where people can see how others are using functional programming to solve real world problems; where practitioners meet and collaborate; where language designers and users can share ideas about the future of their favorite language; and where one can learn practical techniques and approaches for putting functional programming to work. ------------------------------------------------------------------------ Giving a CUFP Talk If you have experience using functional languages in a practical setting, we invite you to submit a proposal to give a talk at the event. We're looking for two kinds of talks: Retrospective reports are typically 25 minutes long. Now that CUFP has run for more than a decade, we intend to invite past speakers to share what they’ve learned after a decade spent as commercial users of functional programming. We will favour experience reports that include technical content. Technical talks are also 25 minutes long, and should focus on teaching the audience something about a particular technique or methodology, from the point of view of someone who has seen it play out in practice. These talks could cover anything from techniques for building functional concurrent applications, to managing dynamic reconfigurations, to design recipes for using types effectively in large-scale applications. While these talks will often be based on a particular language, they should be accessible to a broad range of programmers. We strongly encourage submissions from people in communities that are underrepresented in functional programming, including but not limited to women; people of color; people in gender, sexual and romantic minorities; people with disabilities; people residing in Asia, Africa, or Latin America; and people who have never presented at a conference before. We recognize that inclusion is an important part of our ission to promote functional programming. So that CUFP can be a safe environment in which participants openly exchange ideas, we abide by the SIGPLAN Conference Anti-Harassment Policy: http://www.sigplan.org/Resources/Policies/Anti-harassment If you are interested in offering a talk, or nominating someone to do so, please submit your presentation before 09 June 2017 via the CUFP 2017 Presentation Submission Form: https://goo.gl/forms/KPloANxHHwdiaoVj2 You do not need to submit a paper, just a short proposal for your talk. There will be a short scribe's report of the presentations and discussions but not of the details of individual talks, as the meeting is intended to be more of a discussion forum than a technical interchange. Nevertheless, presentations will be recorded and presenters will be expected to sign an ACM copyright release form. Note that we will need presenters to register for the CUFP workshop and travel to Oxford at their own expense. There are some funds available to would-be presenters who require assistance in this respect. ------------------------------------------------------------------------ Program Committee Alex Lang (Tsuru Capital), co-chair Rachel Reese (Mulberry Labs), co-chair Garrett Smith (Guild AI) Danielle Sucher (Jane Street) Jasper Van der Jeugt (Fugue) Yukitoshi Suzuki (Ziosoft) Evelina Gabasova (University of Cambridge) Brian Mitchell (Jet.com) ------------------------------------------------------------------------ More information For more information on CUFP, including videos of presentations from previous years, take a look at the CUFP website at http://cufp.org. Note that presenters, like other attendees, will need to register for the event. Acceptance and rejection letters will be sent out by July 15th. Guidance on giving a great CUFP talk Focus on the interesting bits: Think about what will distinguish your talk, and what will engage the audience, and focus there. There are a number of places to look for those interesting bits. Setting: FP is pretty well-established in some areas, including formal verification, financial processing, and server-side web services. An unusual setting can be a source of interest. If you're deploying FP-based mobile UIs or building servers on oil rigs, then the challenges of that scenario are worth focusing on. Did FP help or hinder in adapting to the setting? Technology: The CUFP audience is hungry to learn about how FP techniques work in practice. What design patterns have you applied, and to what areas? Did you use functional reactive programming for user interfaces, or DSLs for playing chess, or fault-tolerant actors for large-scale geological data processing? Teach us something about the techniques you used, and why we should consider using them ourselves. Getting things done: How did you deal with large-scale software development in the absence of pre-existing support tools that are often expected in larger commercial environments (IDEs, coverage tools, debuggers, profilers) and without larger, proven bodies of libraries? Did you hit any brick walls that required support from the community? Don't just be a cheerleader: It's easy to write a rah-rah talk about how well FP worked for you, but CUFP is more interesting when the talks also cover what doesn't work. Even when the results were all great, you should spend more time on the challenges along the way than on the parts that went smoothly.

1 1