News aggregator

The GHC Team: GHC 8.0.1 is available!

Planet Haskell - Sat, 05/21/2016 - 7:24am

The GHC developers are very pleased to announce the release of the first new super-major version of our Haskell compiler in six years, GHC 8.0.1. This release features dozens of exciting developments including,

  • A more refined interface for implicit call-stacks, allowing libraries to provide more helpful runtime error messages to users
  • The introduction of the DuplicateRecordFields language extension, allowing multiple datatypes to declare fields of the same name
  • Significant improvements in error message readability and content, including facilities for libraries to provide custom error messages, more aggressive warnings for fragile rewrite rules, and more helpful errors for missing imports
  • A rewritten and substantially more thorough pattern match checker, providing more precise exhaustiveness checking in GADT pattern matches
  • More reliable debugging information including experimental backtrace support, allowing better integration with traditional debugging tools
  • Support for desugaring do-notation to use Applicative combinators, allowing the intuitive do notation to be used in settings which previously required the direct use of Applicative combinators
  • The introduction of Strict and StrictData language extensions, allowing modules to be compiled with strict-by-default evaluation of bindings
  • Great improvements in portability, including more reliable linking on Windows, a new PPC64 code generator, support for the AIX operating system, unregisterised m68k support, and significant stabilization on ARM targets
  • A greatly improved user's guide, with beautiful and modern PDF and HTML output
  • Introduction of type application syntax, reducing the need for proxies
  • More complete support for pattern synonyms, including record pattern synonyms and the ability to export patterns "bundled" with a type, as you would a data constructor
  • Support for injective type families and recursive superclass relationships
  • An improved generics representation leveraging GHC's support for type-level literals
  • The TypeInType extension, which unifies types and kinds, allowing GHC to reason about kind equality and enabling promotion of more constructs to the type level
  • ...and more!

A more thorough list of the changes included in this release can be found in the ​release notes,

As always, we have collected various points of interest for users of previous GHC releases on the GHC 8.0 migration page, Please let us know if you encounter anything missing or unclear on this page.

This release is the culmination of nearly eighteen months of effort by over one hundred contributors. We'd like to thank everyone who has contributed code, bug reports, and feedback over the past year. It's only because of their efforts that GHC continues to evolve.

How to get it

Both the source tarball and binary distributions for a wide variety of platforms are available here.


Haskell is a standardized lazy functional programming language.

The Glasgow Haskell Compiler (GHC) is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license.

Supported Platforms

The list of platforms we support, and the people responsible for them, can be found on the GHC wiki

Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform.


We welcome new contributors. Instructions on getting started with hacking on GHC are available from GHC's ​developer site.

Community Resources

There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the Mailman ​web interface.

There are several other Haskell and GHC-related mailing lists on ​; for the full list, see the ​lists page.

Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too. See the ​Haskell wiki for details.

Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here.

Categories: Offsite Blogs

Proposal: add fromRight and fromLeft to Data.Either

libraries list - Fri, 05/20/2016 - 9:08pm
When working with Either, I am often missing two simple functions: fromRight :: Either a b -> b fromLeft :: Either a b -> a It has been implemented a couple of times: But I don't want to depend on yet another library for such a basic function. Could it be added? Anton
Categories: Offsite Discussion

Modeling space for a MUD - revisited.

haskell-cafe - Fri, 05/20/2016 - 5:47pm
This is a continuation of a conversation started in the following two links.!searchin/haskell-cafe/michael$20litchard|sort:date/haskell-cafe/n0Tc29UUgoQ/iitt3z3PCwAJ!searchin/haskell-cafe/michael$20litchard|sort:date/haskell-cafe/qD2kaZ9qpEA/jTDAp8KoCgAJ I am trying to model a 3-D space for a mudlike. Here's the criteria I have so far: (1) Objects in space will be either ships that can move or stationary things like non-moving game-controlled ships, space-stations , moons and planets. (2) Objects will not have spatial extent (3) Space is non-continuous (4) Collision happens only when one object is stationary or each moving objects are moving directly toward each other, on the same line. (5) Movement happens by setting a destination vector and a speed. There's no steering exactly, but you can change destination while moving, slow down or stop suddenly. (6) Octree looks like the data structure I want to use for modeling. I'm looking a
Categories: Offsite Discussion

Neil Mitchell: Another space leak: QuickCheck edition

Planet Haskell - Fri, 05/20/2016 - 8:29am

Summary: QuickCheck had a space leak in property, now fixed (in HEAD).

Using the techniques described in my previous blog post I found another space leak, this time in QuickCheck, which has now been fixed. Using QuickCheck we can chose to "label" certain inputs, for example:

$ quickCheck $ \p -> label (if p > 0 then "+ve" else "-ve") True
+++ OK, passed 100 tests:
54% -ve
46% +ve

Here we label numbers based on their value, and at the end QuickCheck tells us how many were in each set. As you might expect, the underlying QuickCheck implementation contains a Map String Int to record how many tests get each label.

Unfortunately, the implementation in QuickCheck-2.8.1 has a space leak, meaning that the memory usage is proportional to the number of tests run. We can provoke such a space leak with:

quickCheckWithResult stdArgs{maxSuccess=10000} $
\(p :: Double) -> label "foo" True

When running with ghc --make Main.hs -rtsopts && Main +RTS -K1K we get the error:

Main: Stack space overflow: current size 33624 bytes.

Using -K1K we have detected when we evaluate the space leak, at the end of the program, when trying to print out the summary statistics. The approach taken by QuickCheck for label is to generate a separate Map String Int per run, then at each step merge these Map values together using unionWith (+). As such, there are two likely culprits for the space leak:

  • Perhaps the Map is not evaluated, so in memory we have unionWith (+) x1 $ unionWith (+) x2 $ unionWith (+) x3 $ ....
  • Perhaps the values inside the Map are not evaluated, so in memory we have Map {"foo" = 1 + 1 + 1 + ...}.

QuickCheck avoids the first space leak by keeping its intermediate state in a record type with a strict field for the Map. QuickCheck suffers from the second problem. As usual, actually fixing the space leak is easy - just switch from importing Data.Map to Data.Map.Strict. The Strict module ensures that the computations passed to unionWith are forced before it returns, and the memory usage remains constant, not linear in the number of tests.

I detected this space leak because the Shake test suite runs with -K1K and when running one particular test on a Mac with GHC 8.0 in profiling mode it caused a stack overflow. I did not diagnose which of those factors was the ultimate cause (it may have even been the random seed at a particular point in time - only certain inputs call label).

Many space leaks are now easy to detect (using -K1K), moderate difficulty to debug (using the -xc technique or just by eye) and usually easy to fix.

Categories: Offsite Blogs

Philip Wadler: Cycling Fallacies

Planet Haskell - Fri, 05/20/2016 - 4:05am
Cycling Fallacies is a handy reference from The Cycling Embassy of Great Britain. A sample entry is copied below. Spotted by Ewen Maclean.

Your cycling fallacy is…<section class="fallacy_claim"> “If you put in a cycle lane, or pedestrianise a road, shops will get less business.”
</section> <section class="fallacy_response"> The ResponseCycling infrastructure (or pedestrianisation) does not restrict access to shops – it can actually make the streets and roads shops are on nicer places to visit, increasing footfall, and overall demand.
Many studies – from the Netherlands in the 1970s, to big US cities in the 2010s – have found that installing cycle infrastructure does not have a negative effect on income of businesses, and in most cases has a positive effect.
It's a popular myth that people who arrive by car spend more. People who arrive at shops on foot, or by bike, may spend less per visit, but they will visit more often, and they will spend more money overall. And being able to access a shop easily by foot or by cycle means that more frequent trips involving smaller ‘baskets’ become more convenient.
The headline message is: well-designed streets that make cycling and walking attractive are good for business. And in any case, cycling infrastructure won't stop people driving to shops, or parking near them and walking a short distance.

Further reading<section id="links_in_main_language"> </section></section>
Categories: Offsite Blogs

ANNOUNCE: accelerate-typelits

haskell-cafe - Thu, 05/19/2016 - 11:16pm
I want to announce my first haskell project big/clean enough so I consider it possibly useful to others - accelerate-typelits is a library that provides vectors/matrices in a typesafe way - i.e. The dimension of the entities are stored on type level as (Nats). There is basic vector/matrix functionality, documentation and tests for those functions (mostly properties). If I have time I will provide some basic examples and a bit more complicated example within the next week. It is available on hackage as well as on github I would be happy to get some feedback. - Martin _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

DSLDI 2016: Call for Talk Proposals

General haskell list - Thu, 05/19/2016 - 10:24pm
********************************************************************* CALL FOR TALK PROPOSALS DSLDI 2016 Fourth Workshop on Domain-Specific Language Design and Implementation October 31, 2016 Amsterdam, Netherlands Co-located with SPLASH ********************************************************************* Deadline for talk proposals: August 1, 2016 *** Workshop Goal *** Well-designed and implemented domain-specific languages (DSLs) can achieve both usability and performance benefits over general-purpose programming languages. By raising the level of abstraction and exploiting domain knowledge, DSLs can make programming more accessible, increase programmer productivity, and support domain-specific optimizations. The goal of the DSLDI workshop is to bring together researchers and practitioners interested in discussing how DSLs should be designed, implemented, supported by tools, and applied in realistic contexts. The focus of the w
Categories: Incoming News

ANNOUNCE: Sifflet 2.3.0 - recursion learning aid / visual programming language

haskell-cafe - Thu, 05/19/2016 - 7:12pm
Sifflet 2.3.0 is now available on Hackage. This release brings Sifflet up to date, so it compiles with GHC 7.10.3, newer versions of depended-on libraries, and builds in a cabal sandbox. Sifflet is the visual, functional programming language and support system for students learning about recursion. Sifflet programmers define functions by drawing diagrams, and the Sifflet interpreter uses the diagrams to show how function calls are evaluated. The Sifflet library (formerly sifflet-lib package) is reintegrated into, and deprecated in favor of, the sifflet package. A test suite is added. Personal Note ------------- It's been about 18 months since I've been able to work on this project or do any serious Haskell development. A lot has changed in the Haskell world -- a lot of catching up to do! It feels good getting back to Haskell again. About Sifflet ------------- Sifflet is a visual, functional programming language intended as an aid for learning about recursion. * A picture explains Sifflet better
Categories: Offsite Discussion

CFP (Approaching Deadline): IEEE DS-RT 2016 - SpecialSession tracks

General haskell list - Thu, 05/19/2016 - 3:37pm
Dear Colleagues and Researchers, Apologies, if you have received multiple copies of this CFP. ********** CALL FOR PAPER ********** 20th IEEE/ACM* International Symposium on Distributed Simulation and Real Time Applications September 21 - 23, 2016, London, UK *IEEE/ACM Pending Upon Approval DS-RT 2016 is running four special sessions this year: - Simulation of Urban Traffic Management and ITS - Distributed Simulations of Distributed Systems - Augmented and Virtual Reality for Real-Time Applications - Agent-based Modeling and Simulation Those special sessions cover prominent areas of the field of distributed simulations and real time applications, and many papers were accepted in previous editions of DS-RT on the same topics. See below for more detailed descriptions of those special sessions. Authors of selected papers will be invited to submit extended versions of their papers to a special issue on "Data-driven and Large-scale Distributed Simulation"
Categories: Incoming News

Proposal: add full complement of support for decreasing things in Data.Map

libraries list - Thu, 05/19/2016 - 3:00pm
Data.Map offers functions to convert from ascending lists to maps, and also offers a function to map an increasing function over the keys of a map. Equivalents for descending lists and decreasing functions are missing. I think we should add them. Any objections? _______________________________________________ Libraries mailing list Libraries< at >
Categories: Offsite Discussion

[ANN] Final Call for Papers: Erlang Workshop 2016 -- Submission deadline (3 June) approaching

General haskell list - Thu, 05/19/2016 - 12:28pm
Apologies for any duplicates you may receive. CALL FOR PAPERS =============== Fifteenth ACM SIGPLAN Erlang Workshop ------------------------------ ----------------------------- Nara, Japan, September 23, 2016 Satellite event of the 21st ACM SIGPLAN International Conference on Functional Programming (ICFP 2016) September 18-24, 2016 The Erlang Workshop aims to bring together the open source, academic, and industrial communities of Erlang, to discuss technologies and languages related to Erlang. The Erlang model of concurrent programming has been widely emulated, for example by Akka in Scala, and even new programming languages were designed atop of the Erlang VM, such as Elixir. Therefore we would like to broaden the scope of the workshop to include systems like those mentioned above. The workshop will enable participants to familiarize themselves with recent developments on new techniques and tools, novel applications, draw lessons from users' experiences and identify research problems and common areas
Categories: Incoming News

RV 2016, Deadline for abstract on May 20 (AoE)

General haskell list - Thu, 05/19/2016 - 10:41am
Following several requests, the deadlines have been extended as follows: - Abstract deadline: Friday May 20 (AoE). - Paper and tutorial deadline: Friday May 27 (AoE). =============================================== RV 2016 16th International Conference on Runtime Verification September 23-30, Madrid, Spain <> Scope Runtime verification is concerned with monitoring and analysis of software and hardware system executions. Runtime verification techniques are crucial for system correctness, reliability, and robustness; they are significantly more powerful and versatile than conventional testing, and more practical than exhaustive formal verification. Runtime verification can be used prior to deployment, for testing, verification, and debugging purposes, and after deployment for ensuring reliability, safety, and security and for providing fault containment and recovery as well as online system repair. Topics of interest to the conference include: - specification
Categories: Incoming News

Brent Yorgey: How to print things

Planet Haskell - Thu, 05/19/2016 - 10:33am

I have finally finished up writing my guide on how to print things, based on this blog post from January on my other (math) blog. It specifically enumerates the pros and cons of various methods for printing and reading loose-leaf documents (the sort of thing that academics do quite a bit, when they print out a journal article to read).

The main motivation for writing the page is to explain the (to my knowledge, novel) Möbius method for printing and reading double-sided, like this:

I actually now use this in practice. As compared to the usual method of printing double-sided, this has several advantages:

  • One always does the exact same action after finishing every page; there is no need to remember whether you are on an even or an odd page.
  • Any consecutive sequence of pages are on different sheets of paper, so it is easy to simultaneously refer to multiple pages close together. There is never any need to keep flipping a sheet back and forth to refer to the previous page (as there is with traditional double-sided printing).

But there are even new things to say about traditional double-sided printing, as well. I now know of several different algorithms for reading double-sided, each with its pros and cons; previously I had not even considered that there might be more than one way to do it.

Categories: Offsite Blogs

Proposal reminder: Add functions to get consecutive elements to Data.List

libraries list - Thu, 05/19/2016 - 6:27am
The discussion period for this proposal is near (31 of May). So far I count 1 for and 2 against the proposal. Joachim Breitner made a good enumeration of some advantages of adding these to base. Here is an enumeration of pros: * Availability in Data.List gives this pattern a common name. * A common name for this makes code easier to read and decreases the risk of getting the definition wrong. * The argument won't have to be repeated, hence making it easier to chain the functions. * List-fusion potential. Tobias Florek pointed out that `zip <*> tail` can be used to define this inline without the need for repeating the argument and made a reference to the Fairbairn threshold. This is elegant, but I am afraid that people might consider this obscure code golfing if used. Cheers Johan Holmquist ---------- Forwarded message ---------- From: Henning Thielemann <lemming< at >> Date: 2016-04-13 13:28 GMT+02:00 Subject: Re: Proposal: Add functions to get consecutive elements to Data.List To:
Categories: Offsite Discussion

What's your favorite flavor of Iterator type

haskell-cafe - Wed, 05/18/2016 - 10:53pm
Hello, We know about Foldable, but sometimes you just want more functionality like: give me the rest of the string! Or a function to build pieces back together. I've been experimenting a bit and come up with 6 flavors of Iterators that do the same thing. Of course they all work for containers like ByteStrings, Text. 1) Haskell98 version (I like) data Iterator98 list ele = Iterator98 { next98 :: Maybe (ele, Iterator98 list ele), ... rest98 :: list, concat98 :: [list] -> list } -- How we can create an Iterator98 listIter98 :: [a] -> Iterator98 [a] a -- How the sum type looks sum98 :: (Num n) => Iterator98 listN n -> n Performance: *3 I'll also usually give the type of the constructor and sum functions. I also benchmarked the sum functions for [] and compared them to the best sum function I could come up with (which is significantly faster than the sum in Prelude!!! because it's strict. Whoever came up with the idea of making it n
Categories: Offsite Discussion

CFP (Approaching Deadline): 19th ACM/IEEE MSWiM 2016

General haskell list - Wed, 05/18/2016 - 4:00pm
==================================================== Call-For-Papers: 19th ACM*/IEEE* MSWiM 2016 Malta, Nov 13-17, 2016 ==================================================== IMPORTANT: Submission deadline: May 30th, 2016 =================================================== *Pending Upon Approval ACM/IEEE* MSWiM 2016 is the 19th Annual International Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems. MSWiM is an international forum dedicated to in-depth discussion of Wireless and Mobile systems, networks, algorithms and applications, with an emphasis on rigorous performance evaluation. MSWiM is a highly selective conference with a long track record of publishing innovative ideas and breakthroughs. MSWiM 2016 will be held Malta, Nov 13-17, 2016 Authors are encouraged to submit full papers presenting new research related to the theory or practice of all aspects of modeling, analysis and simulation of mobile and wireless systems. Submitted papers must
Categories: Incoming News

SPLASH'16: 1st Call for Contributions to Collocated Events

General haskell list - Wed, 05/18/2016 - 11:57am
################################################# ACM Conference on Systems, Programming, Languages, and Applications: Software for Humanity (SPLASH'16) ################################################# Amsterdam, The Netherlands Sun 30th October - Fri 4th November , 2016 Sponsored by ACM SIGPLAN Combined Call for Contributions to SPLASH tracks, collocated conferences, symposia and workshops: - SPLASH-I, Doctoral Symposium, Student Research Competition, Programming Languages Mentoring Workshop, Posters - Dynamic Languages Symposium (DLS) - Generative Programming: Concepts & Experiences (GPCE) - Software Language Engineering (SLE) - Scala Symposium - Workshops: AGERE, DSLDI, DSM, FOSD, ITSLE, LWC< at >SLE, META, MOBILE!, NOOL, PLATEAU, Parsing< at >SLE, REBLS, RUMPLE, SA-MDE, SEPS, VMIL, WODA The ACM SIGPLAN conference on Systems, Programming, Languages and Applications: Software for Humanity (SPLASH) embraces all aspects
Categories: Incoming News

Lee Pike: Max: Phase 1 Report

Planet Haskell - Wed, 05/18/2016 - 10:24am

I sent the following R&D report to my colleagues, but a few other folks outside Galois have expressed interest in the project, so I’m sharing it more broadly.


Subject: Max: Phase 1 Report

As some of you know, about nine months ago, I started a skunk-works R&D project with Brooke. Autonomous systems are all the rage these days, so we decided to try to create one. First, I have to be honest and say that although I participated in the initial project kickoff, I mostly played a supporting role after that. Brooke did all the major software and hardware development. (If you’ve worked with me on a project, this should sound pretty familiar.) Once Brooke started development, she really threw herself into it. She seemed to be working on things day and night, and it even looked a bit painful at times. She sensed she was getting close to an alpha release a few days ago, and after a final four hour sprint, she made the release at 2:30am on Mothers Day! We are officially out of stealth mode.

We call our project “Machine Awareness X”, or Max for short. The current system is capable of basic knowledge discovery and processing. Now, don’t get too excited; we expect at least a few years before it’s able to do something interesting with the knowledge acquired. I won’t go into the technical details, but the programming model is very biological—think “Game of Life” on steroids. At this point, we’ll have to continue to provide guidance and some rules, but its basically self-programming.

Following a “Johnny Ive” approach to design, Max has basically one notification method. It’s a fairly piercing audio signal used whenever his power supply is running low or there’s a hardware problem. (Frankly, sometimes it seems to just go off for no reason at all.) We designed it to be loud enough to hear across the house, but I wish it had a volume control. Next time! Otherwise, the package is quite attractive, in my opinion, even cute. Unfortunately, at 7lbs. 8oz., the hardware is heavier than even a decade-old laptop, and we expect new versions to require an even larger form factor. Fortunately, we designed the system to be self-propelling, although it’ll take a few years before that hardware is developed (the software isn’t ready for it anyways).

There’s still quite a bit of work to do. Our back-of-the-envelope estimate is that we’ll have to spend just short of two decades caring for Max before he’s fully autonomous. Even more disappointingly, we’re estimating having to spend up to a quarter million (in today’s dollars) in upkeep and maintenance! (Sadly, while others are interested in playing with the system intermittently, nobody seems that interested in joining us as early investors.) Despite all the training we’re planning to provide, the system seems too complicated to guarantee certain behaviors. For example, while more general than an autonomous car, it may take more than 15 years of training before his software is capable of piloting a conventional automobile.

I’m guessing some of you are wondering about commercialization opportunities. The good news: we expect Max to be useful to society (we haven’t found a killer app yet, though) and to generate quite a bit of revenue over its lifetime. The bad news: we don’t expect it to start producing reliable revenue for more than 20 years. What’s more, it has a lot of upkeep expenses that will only grow with time. This might sound like science fiction, but we imagine he might even replicate himself in the distant future, and will likely pour his revenues into his own replicants. In short, we don’t expect to make a dime from the project.

More seriously, we had a kid; mom and baby are doing fine. See you soon.

Papa Pike

Categories: Offsite Blogs

Call for contribution, PLRR 2016 (Parametricity, Logical Relations & Realizability), CSL affiliated workshop

General haskell list - Wed, 05/18/2016 - 9:59am
CALL FOR CONTRIBUTIONS Workshop PLRR 2016 Parametricity, Logical Relations & Realizability September 2, Marseille, France Satellite workshop - CSL 2016 BACKGROUND The workshop PLRR 2016 aims at presenting recent work on parametricity, logical relations and realizability, and encourage interaction between those communities. The areas of interest include, but are not limited to: * Kleene's intuitionistic realizability, * Krivine's classical realizability, * other extensions of the Curry-Howard correspondence, * links between forcing and the Curry-Howard correspondence, * parametricity, * logical relations, * categorical models, * applications to programming languages. INVITED SPEAKERS Neil Ghani (University of Strathclyde) Nick Benton (Microsoft Research, Cambridge) CONTRIBUTED TALKS We so
Categories: Incoming News

Yesod Web Framework: Are unused import warnings harmful?

Planet Haskell - Wed, 05/18/2016 - 12:15am

Which of the following snippets of code is better?

#if MIN_VERSION_base(4,8,0) import Control.Applicative ((<*)) #else import Control.Applicative ((<*), pure) #endif


import Control.Applicative ((<*), pure)

If you are working on a project that supports multiple GHC versions, enable extra warnings via -Wall, and actually like to get your code to compile without any warnings, you'll probably say that the former is better. I'm going to claim, however, that any sane human being knows intuitively that the latter is the better version of the code, for multiple reasons:

  • It doesn't require a language extension to be enabled
  • It's much shorter without losing any useful information to the reader
  • It's more robust to future changes: if you need to add an import, you don't have to remember to update two places

However, if you look through my code bases, and the code bases of many other open source Haskell authors, you'll find the former examples regularly. I'm beginning to come to the conclusion that we've been attacking this problem the wrong way, and what we should be doing is:

  • Turning on -Wall in our code
  • Either modify -Wall in GHC to not warn about unused imports, or explicitly disable unused import warnings via -fno-warn-unused-imports
  • As many of us already do, religiously use Travis CI to check multiple GHC versions to avoid accidental regressions
  • In our Travis builds, start turning on -Werror

Maintaining complex CPP in our imports is sometimes a necessary evil, such as when APIs change. But when we are simply doing it to work around changes in what Prelude or other modules export, it's an unnecessary evil. This is similar to the change to GHC a few years back which allowed hiding (isNotExported) to not generate a warning: it made it much easier to deal with the now-no-longer-present Prelude.catch function.

While it's true that removing unused imports is a nice thing to do to our codebases from time to time, their presence does not actually indicate any potential issues with our code. My concern with the presence of these warnings is that they will lead to one of two situations:

  • We simply accept that our libraries generate warnings when compiled, which ends up hiding actionable warnings via a terrible signal-to-noise ratio
  • In an effort to clean up all warnings, we end up creating hideous messes like those above, or breaking backwards compatibility with old versions of dependencies

I haven't actually started making these modifications to my libraries, as I'm not yet fully convinced that this is a good idea. There are also other points in this design space, like explicitly marking some imports as redundant, though that would require some deeper changes to GHC and wouldn't be usable until we drop support for all current GHC versions.

Categories: Offsite Blogs