Language level heads-up warnings

Simon Peyton-Jones simonpj at
Wed May 22 15:42:10 CEST 2013

Yes, I think that if the libraries community thought it was important, I (or indeed someone else) could add a couple of ad-hoc warnings to GHC without much work. But you'd all need to be clear and specific about what warnings were wanted, and they'd need to be easy to check (ie no global program analysis).


-----Original Message-----
From: ghc-devs-bounces at [mailto:ghc-devs-bounces at] On Behalf Of David Luposchainsky
Sent: 22 May 2013 12:36
To: ghc-devs at
Subject: Language level heads-up warnings

Hello GHC-Devs,

The discussion on the libraries mailing list brought up the issue of breaking compatbility in favour of language evolution/sanitation again; topics mentioned specifically were Prelude's monomorphic Foldable/Traversable functions, and the Applicative/Monad issue.

The main arguments of both sides are these:

(+) We've been aware of certain unfortunate features of Base for a long time, and we understand very well how to fix this, and what the consequences are.

(-) Changing core language features is something you can never forsee the consequences of. Breaking compatibility should be avoided at all costs.

(There's also the argument about beginner friendliness, which is not backed by evidence, so I'll leave it out here.)

These two seem contradictory, however they have one almost obvious common ground: we can already write code right now that will be unaffected by moving Foldable/Traversable/Applicative+Monad to the Prelude. Suppose all code is written with this in mind, the change is trivial.

Which brings us to the actual problem, namely that code is not written with this in mind. It is easy to forget about the issue in a practical setting, regardless of how small the required effort is. Therefore, I'd like to bring forward the idea of "language level heads-up warnings"
(suggestions for better names appreciated).

Right now, we can only deprecate functions. When used, GHC informs us "hey, this will work for now, but better use that in the future".
However, this mechanism is too specialized to tackle the problem above:
for example, there is no way to warn a user about a Monad that is not an Applicative.

If the community agrees on making one of the "big" changes, what would you think of adding warnings about language usage? I'm sure over the course of a couple of GHC releases, the great majority of libraries would be modified to rectify these warnings again. If you want an
example: "Warning: Monad without Applicative. This will be enforced in a future language standard."

These warnings would have to be hardcoded into GHC, but keep in mind that this is only for very few, relatively high impact changes, and can be removed once everything is done. In my opinion, this may be a far better transitional feature than the alternative (adding compatibility modules, convincing thousands of developers to listen to the people in favour of the change, ...).


ghc-devs mailing list
ghc-devs at

More information about the ghc-devs mailing list