Erik de Castro Lopo | 6 May 11:04 2016

RFC: Removing the `-hb` profiling option

Hi all,

After a bit of rather tedious and frustrating debugging I came to the
realisation that the code for the `-hb` profiling option is not thread
safe. See

This gives us an opportunity to simply remove it instead of fixing it.
If there is anyone that thinks this future is really useful (ie more
useful than the other profiling modes) then I'm willing to fix it.
But if noone would miss it. I'd much rather remove it.



Erik de Castro Lopo
Volker Wysk | 5 May 21:19 2016

What happened to -optdep option?


I'm using GHC 7.10.3 after an upgrade. I have the following in my Makefile:

depend_mod :: lib/abh
	ghc -M $(CFLAGS_GHC_0) -dep-makefile -optdepbuild/depend.tmp -dep-suffix "p_" 
	       $(foreach m, $(MOD_HS) $(PROG_HS), src/$(m).hs) \
	       $(foreach m, $(MOD_CHS) $(PROG_CHS), build/$(m).hs)

This used to work. The previous GHC version was 7.8. 

Now GHC complains:

-optdepbuild/depend.tmp: openBinaryFile: does not exist (No such file or 

This looks like the -optdep argument isn't understood. There is no mention of 
it in the new/7.10.3 user manual. I don't know any longer what this "-optget" 
argument does, and it isn't in the documentation any longer.

I googled the GHC web site. There it is mentioned that -optdep was deprecated, 
but almost all of the hits are very outdated (like ten years old).

Can soneone tell me, how I should change my Makefile..?

Volker Wysk
(Continue reading)

Ben Gamari | 28 Apr 11:10 2016

[ANNOUNCE] GHC 8.0.1 release candidate 4 available

Hello Haskellers,

The GHC team is happy to announce the availability of fourth release
candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and
binary distributions can be found at,

This is the last of four candidates leading up to the 8.0.1 release,
addressing nearly all of the known issues of the previous candidates.
These include,

  * A type-checker panic triggered by use of Typeable on a
    kind-polymorphic type constructor (#11334)

  * A type-checker explosion where -XTypeInType would gobble up massive
    amounts of memory when used in a data instance (#11407)

  * A variety of other typechecker issues (#11811, #11797, #11813,

  * A build issue seen on OS X (#11828)

  * Template Haskell can now produce instances with

  * Autoconf has improved version checks for libdw (#11820)

  * Typeable and hs-boot files now interact nicely (#11824)
(Continue reading)

AntC | 26 Apr 10:20 2016

Magic classes for Overloaded Record Fields, overlaps, FunDeps

There's an intriguing comment here wrt anonymous records:
(End of the section)

"... this doesn't quite work, because the two instances overlap,
 but it is possible with a bit more trickery"

I could well understand if everybody's forgotten what was the "trickery", 
because ORF has been so long in the pipeline, but could anyone explain?

Reason for the q: I'm looking at anonymous records myself,
 including extending, shortening and joining anon records. 
And yes overlapping instances are everywhere.

Using type families isn't being too ergonomic. And I notice ORF has used FunDeps.
But for me, FunDeps in the HList style is also rather ugly.

Is there some trickery I'm missing?

John Williams | 18 Mar 19:27 2016

idea: tool to suggest adding imports

I have an idea for a tool I'd like to implement, and I'm looking for advice on the best way to do it.

Ideally, I want to write an Emacs extension where, if I'm editing Haskell code and I try to use a symbol that's not defined or imported, it will try to automatically add an appropriate import for the symbol. If instance, if I have "import Data.Maybe (isNothing)" in my module, and I try to call "isJust", the extension would automatically change the import to "import Data.Maybe (isJust, isNothing)".

The Emacs part is easy, but the Haskell part has me kind of lost. Basically I want to figure out how to heuristically resolve a name, using an existing set of imports as hints and constraints. The main heuristic I'd like to implement is that, if some symbols are imported from a module M, consider importing additional symbols from M. A more advanced heuristic might suggest that if a symbol is exported from a module M in a visible package P, the symbol should be imported from M. Finally, if a symbol is exported by a module in the Haskell platform, I'd like to suggest adding the relevant package as a dependency in the .cabal and/or stack.yaml file, and adding an import for it in the .hs file.

Here are some implementation options I'm considering:

1. Add a ghci command to implement my heuristics directly, since ghc already understands modules, packages and import statements.
2. Load a modified version of the source file into ghci where imports like "import M (...)" are replaced with "import M", and parse the error messages about ambiguous symbols.
3. Write a separate tool that reads Haskell imports and duplicates ghc and cabal's name resolution mechanisms.
4. Write a tool that reads Haskell imports and suggests imports from a list of commonly imported symbols, ignoring which packages are actually visible.

Right now the options that look best to me are 2 and 4, because the don't require me to understand or duplicate big parts of ghc, but if modifying ghc isn't actually that hard, then maybe 1 is the way to go. Option 3 might be a good way to go if there are libraries I can use to do the hard work for me.

Any thoughts?
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>
Tom Sydney Kerckhove | 16 Feb 18:12 2016

[Feedback requested]: -fhelpful-import-errors


I raised a ticket to request a new feature: -fhelpful-import-errors.

This flag should enable helpful errors if there are typo's in the
internal imports of your projects.

As suggested by `thomie`, I created a design proposal at
and am now looking for feedback.

Thank you for your time.


Tom Sydney Kerckhove
Evan Laforge | 15 Feb 01:32 2016

LANGUAGE ConstraintKinds not needed to use ConstraintKinds?

I recently upgraded to ghc 8 and started using stacks via
ImplicitParams.  For that I wind up using 'type Stack = (?stack ::
CallStack)' and so ContraintKinds (I see that in the future GHC will
do this by default).

So now I can have a file like:

module T where
import qualified Log as Log

f :: Log.Stack => IO ()
f = Log.warn "blah blah"

I noticed that now haskell-src-exts refuses to parse this file, saying
'MultiParamTypeClasses language extension is not enabled.'.

I assume it's a bug with haskell-src-exts in that it should require
LANGUAGE ConstraintKinds instead, but then GHC itself doesn't want
ConstraintKinds.  Instead, it wants FlexibleContexts.  From the docs,
FlexibleContexts seems to be about the contexts in instance heads.

Is this intentional?  I'll go ahead and make a bug for
haskell-src-exts, but the ghc behaviour here seems odd as well.  What
extension should haskell-src-exts require to parse this?
Ben Gamari | 14 Feb 17:12 2016

Reconsidering -Wall and -Wcompat

tl;dr. GHC has a new set of warnings, -Wcompat, intended to give users
       advance notice of coming library changes. We want to know whether
       you think this set should be included in -Wall. See the Wiki [4]
       and voice your opinion via the linked poll.

Hello everyone,

GHC 8.0.1 will include a new warning group, -Wcompat, which arose out of
the MonadFail proposal discussion [1] late last year. This warning set
is intended to provide a means of informing users of coming changes in
GHC's core libraries.

We would like to solicit the community's feedback on whether this new
flag set should be implied by -Wall.

This proposal is motivated by concern expressed by some that -Wcompat
would see little usage unless it is placed in one of the warning sets
typically used during development. One such set is -Wall, which enables
a generous fraction of GHC's warning collectionand is is intended [2]
for use during development.

Unfortunately, despite the (albeit only recently stated) intent of
flag, -Wall is widely used outside of development [3], often with the
expectation that the result be warning-clean across multiple GHC
versions. While we hope that -Wall will see less use in this context in
the future, given its current role we wouldn't want to add options to it
that would cause undue burden for users.

So, we are asking for your opinion: should -Wcompat be implied by -Wall?
You can find a more thorough description of the precise proposal on the
GHC Wiki [4]. It would be very much appreciated if you could take a few
minutes familiarize yourself with the options and provide your thoughts
via this quick poll,

Feel free to discuss the issue further in this thread.

Thank you for sharing,

- Ben



[3] In a rather unscientific study, nearly half of packages on Hackage
    include it in ghc-options,

        $ tar -xf ~/.cabal/packages/00-INDEX.tar
        $ (for pkg in $(ls); do ls $pkg/*/*.cabal | sort -r | head -n1; done) | xargs grep -L '\-Wall' | wc -l
        $ ls | wc -l 
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>
Ben Gamari | 7 Feb 19:13 2016

[ANNOUNCE] GHC 8.0.1 release candidate 2

Hello everyone,

The GHC Team is very pleased to announce the second release candidate of
the Glasgow Haskell Compiler 8.0.1 release. Source and binary
distributions as well as the newly revised users guide and Haddock
documentation can be found at

This is the second in a series of release candidates leading up to the 8.0.1
release and fixes many of the issues reported in -rc1. These fixes

  * A re-rewrite of the pattern checker by George Karachalias. The new
    checker should have far more predictable performance characteristics
    while sacrificing minimal reasoning power. This should resolve a
    large number of the issues felt in -rc1.

  * Richard Eisenberg has been hammering out all manner of
    type-application- and TypeInType-related issues (#11335, #11416,
    #11405). There is still more work to do here, however (e.g. #11471).

  * Matthew Pickering has restored support for multi-clause pattern
    synonyms (#11367)

  * A latent bug in the constraint solver which popped up as a build
    failure in xmonad-contrib in -rc1 has been fixed (#11379)

  * Dimitrios Vytiniotis and Simon Peyton Jones has been squashing a
    variety of older type-checker bugs at a furious rate (#11458,
    #11248, #11330, #11408)

  * Simon Peyton Jones has taught demand analysis to more precisely
    handle exceptions (#11222)

  * Tamar Christina has added support for remote GHCi on Windows
    and resolved a long-standing linking issue (#11223)

  * Loading of compiled modules needing shared library symbols now works
    in GHCi thanks to Peter Trommler (#10458)

  * A variety of limitations in our implementation of Typeable
    implementation have been fixed (#11120) although there is still more
    to be done (#11334).

  * A terrible failure of type inference due to visible type application has
    been fixed (#11458)

  * InjectiveTypeFamilies has been renamed to TypeFamilyDependencies

  * Custom type errors are now more robust (#11391) although there is
    still more work to be done (#11541)

  * We now have a more conservative default warning set, as well as
    better mechanisms for managing warning changes in the future.
    (#11429, #11370)

  * Compatibility with earlier Cabal versions should be a bit more

  * The user-facing interface of the (formerly "implicit") CallStack
    functionality has been reworked, hiding the implicit callstack
    parameter behind a constraint synonym.

  * Online haddock documentation has been restored (#11419)

  * We now offer xz archives exclusively

  * A variety of miscellaneous bug-fixes have also been merged.

All of these changes add up to nearly 200 commits in total. Given the
large amount of churn between this candidate and -rc1, as well as the
fact that there is at least one more significant patch pending (D1891,
to fix #11471 and others), we will be releasing a third release
candidate in a few weeks which should address more of the issues listed
on the release status page [1]. Assuming things go well, we should be
able to cut a final release by early March at the latest.

All of the builds above were produced from the ghc-8.0.1-rc2 tag (commit
e2230228906a1c0fa1f86a0c1aa18d87de3cc49d) *with the exception of the
Windows builds*. Unfortunately, it was realized only too late that the
tagged commit is broken on Windows. Consequently, the Windows builds
were produced from the ghc-8.0.1-rc2 tag with two additional patches
(commit 5b35c5509adb1311856faa0bc9767aec9ad5e9b7). While this would of
course be completely unacceptable for a proper release, time constraints
have meant that this was unfortunately the only viable option for this
release candidate. We apologize for any confusion this may cause.

At this point we are working very hard to nail the remaining bugs
labelled as "highest" priority on the 8.0.1 status page [1]. If you have
an issue which you'd like to see addressed in the release that does not
appear in this list, please bring it to our attention.

As always, we look forward to hearing about any issues that you
encounter with this candidate. Thanks to everyone who has contributed so


 - Ben

Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>
Philip Dexter | 22 Jan 00:14 2016

Were usage types ever in GHC

I've recently been digging around to see if there has ever been any 
attempt to perform any sort of data reuse optimization in functional 

Along with many other papers, I've come across `Once upon a type' as well 
as `Once upon a polymorphic type'. They both mention a desire to include a 
similar system in GHC.

Then in `Playing by the rules: rewriting as a practical optimization 
technique in GHC' I see usage types mentioned in section 5.3:

To express this, GHC adds extra usage type arguments to map, both at its 
definition and at its call sites. Once this is done, a specialised version 
of map can be compiled for the case when the usage-type argument is 
“once”, and a rule generated to match such calls, in exactly the same way 
as for specialising overloading.

I can't tell if this is simply a hypothetical optimization or if this 
really happened at one point in the history of GHC.

I was hoping somebody could shed some light on this topic

Was a usage type system or something similar (e.g. linear type system) 
ever present in GHC?

If it was then why was it taken out (unless I'm missing something, this 
optimization is not happening today)? I could guess at this and say that 
the gains weren't worth the overhead, but perhaps there's another reason.

If it was never present, why not? There was obviously at least some 
interest in this sort of optimization at some point in the Haskell 
community and I'd be curious as to why it was never tested in GHC.


Philip Dexter
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>
Ben Gamari | 13 Jan 17:19 2016

Dropping bzip2 release tarballs?

tl;dr do you rely on the .bz2 release tarballs on
      If so, let us know!

Hello everyone,

As you may have noticed, a few releases ago we started producing
xz-compressed binary distributions in addition to the usual bzip2

While preparing 8.0.1-rc1 it was suggested that we move to distributing
xz tarballs exclusively. Not only would this move reduce storage and
bandwidth demands on our infrastructure but it would also simplify the
job of producing the distributions. Indeed there is plenty of precendent 
for projects who have moved exclusively to xz (the Linux kernel and git
being two examples).

Of course, these reasons alone aren't sufficient to abandon those who
might rely on our bzip2 tarballs. If you feel strongly that we should
continue to distribute bzip2 tarballs, please let us know.


- Your friendly GHC packaging gnomes
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>