- Glasgow-haskell-users

Re: [Maintainer needed] Actively maintained Haddock are happy Haddock
by Ben Gamari 06 May '16

06 May '16

Sebastian <arnaudpourseb(a)gmail.com> writes: > Hello Ben, > Hi Sebastian, Sorry for the belated response. > If that's ok I'd be happy to take over the maintenance of Haddock. > Sure, that would be great. I can give you the keys in a bit. Cheers, - Ben

1 0

What happened to -optdep option?
by Volker Wysk 06 May '16

06 May '16

Hello! 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 directory) 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..? Greetings, Volker Wysk

2 2

[Maintainer needed] Actively maintained Haddock are happy Haddock
by Ben Gamari 04 May '16

04 May '16

tl;dr. Our Haddock need a dedicated maintainer responsible for their care and feeding. Would you like to move forward a critical piece of infrastructure used on a daily basis by thousands of Haskellers? Let us know if so. Hello everyone, While for several years Mateusz Kowalczyk and Simon Hengel have done an admirable job in serving as comaintainers of the Haddock documentation tool, they have both indicated that they no longer have the time to continue to be active in this role. They both deserve our thanks for their service. While Matthew Pickering and I have tried to pick up some of the Haddock's maintenance load in the meantime, we really need a dedicated maintainer to ensure that Haddock continues to swim along healthfully. At the moment there are over 150 open tickets in the issue tracker [1], an open call for a stable release, and 4 patches in need of review. We currently lack the time to get on top of such a load. In particular, Haddock need someone to take ownership of the management of the project: this person would keep an eye on (and preferably pare down) the issue tracker (which typically isn't very active, happily), guide new contributors, and manage releases. This is an opportunity to drive forward a project used on a daily basis by a significant fraction of Haskellers. If you think you might be interested in serving in this role, please let us know. Thanks! Cheers, - Ben [1] https://github.com/haskell/haddock/pulls

1 0

[ANNOUNCE] GHC 8.0.1 release candidate 4 available
by Ben Gamari 29 Apr '16

29 Apr '16

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, http://downloads.haskell.org/~ghc/8.0.1-rc4/ 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, #11814) * A build issue seen on OS X (#11828) * Template Haskell can now produce instances with OVERLAPP{ING,ABLE,ED} pragmas * Autoconf has improved version checks for libdw (#11820) * Typeable and hs-boot files now interact nicely (#11824) * The build system now checks for the broken Apple `nm` utility (#11823, #11744) * Various issues involving unexpected laziness resulting in exception handlers not being invoked (#11555) * GHC now fails more gracefully when used with an older cabal-install release (#11558) * TypeInType now has proper documentation in the users guide (#11614) * The story surrounding type `RuntimeRep`s (formerly known as `Levity`) is now far better developed, closing several doors to unsafe behavior that TypeInType previously opened (#11473, #11723) * A long-standing bug in the constant-folding rules for `mod` for the `Word` type has been resolved (#11702) * Various issues introduced by OverloadedRecordFields have been fixed (#11662, #11401) * A regression in the typechecker resulting in the rejection of code in the `free` and `microlens` packages has been fixed (#11608) * A bug in the LLVM code generator which caused some programs to emit unbuildable LLVM IR has been fixed (#11649) * A bug where pattern synonyms defined in terms of a pattern match on a record would be rejected if the fields weren't written in the same order as they were defined has been resolved (#11633) * A bug in the runtime system's treatment of weak references which could result in segmentation faults in some cases has been fixed (#11108) * a variety of optimizations improving compiler performance have been merged * and many others Mac OS X users should be aware that the recent XCode 7.3 release ships with a broken `nm` utility which breaks the GHC build (#11744, #11823). The build system will check for this condition and request that the tree is configured to use the `nm-classic` utility if found. OS X users running XCode 7.3 are encouraged to open a ticket with Apple so that this issue may be fixed in future XCode releases. If no major issues pop up we expect that this will be the last release candidate before the final release, which we hope to push out in the coming weeks. Thanks to everyone who has contributed code, testing, builds, and bug reports thusfar! Cheers and happy testing, - Ben

3 2

[ANNOUNCE] GHC 8.0.1 release candidate 3 available
by Ben Gamari 23 Apr '16

23 Apr '16

Hello Haskellers, The GHC team is happy to announce the availability of third release candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and binary distributions can be found at, http://downloads.haskell.org/~ghc/8.0.1-rc3/ This is the third of what will be four candidates leading up to the 8.0.1 release. As there are a number of known issues with this candidate, we expect to produce the fourth and final release candidate shortly. While we considered not releasing this candidate at all and instead skipping to rc4, we decided that it would be helpful to make it available despite its issues to increase the likelihood of catching any remaining bugs. That being said, this candidate lacks the range of binary distributions which we usually offer, * We are unable to release Windows bindists due to a compatibility issue which we didn't catch until after preparing the source distribution. * Binaries targeting Redhat distributions are currently not available Regardless, users for whom a distribution is available are encouraged to try this candidate as it fixes dozens of issues present in release candidate two. 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) * Various issues involving unexpected laziness resulting in exception handlers not being invoked (#11555) * GHC now fails more gracefully when used with an older cabal-install release (#11558) * TypeInType now has proper documentation in the users guide (#11614) * The story surrounding type `RuntimeRep`s (formerly known as `Levity`) is now far better developed, closing several doors to unsafe behavior that TypeInType previously opened (#11473, #11723) * A long-standing bug in the constant-folding rules for `mod` for the `Word` type has been resolved (#11702) * Various issues introduced by OverloadedRecordFields have been fixed (#11662, #11401) * A regression in the typechecker resulting in the rejection of code in the `free` and `microlens` packages has been fixed (#11608) * A bug in the LLVM code generator which caused some programs to emit unbuildable LLVM IR has been fixed (#11649) * A bug where pattern synonyms defined in terms of a pattern match on a record would be rejected if the fields weren't written in the same order as they were defined has been resolved (#11633) * A bug in the runtime system's treatment of weak references which could result in segmentation faults in some cases has been fixed (#11108) * a variety of optimizations improving compiler performance have been merged * and many others Mac OS X users should be aware that the recent XCode 7.3 release ships with a broken `nm` utility which breaks the GHC build (#11744, #11823). Unfortunately, this candidate does not notice this brokenness and odd behavior can result. OS X users running XCode 7.3 are encouraged to open a ticket with Apple and build GHC with the `--with-nm=nm-classic` configure option until a fix is available. As mentioned earlier, there are a number of known issues with this candidate which will be addressed in release candidate four. These issues include, * A number of typechecker bugs (#11811, #11797, #11813, #11814) * A build issue seen on OS X (#11828) * Template Haskell lacks the ability to produce instances with OVERLAPP{ING,ABLE,ED} pragmas * Autoconf has inadequate version checks for libdw (#11820) * Typeable and hs-boot files interact poorly (#11824) * The build system doesn't check for the broken Apple `nm` utility, leading to unpredictable results (#11823, #11744) We hope to have release candidate four available by the middle of next week. Thanks to everyone who has contributed code, testing, builds, and bug reports thusfar! Cheers, - Ben

2 1

Warn about unwanted instances in a modular way
by Henning Thielemann 23 Mar '16

23 Mar '16

I like to propose the following way to warn about instances that are unwanted by some programmers. First step is to mark the instances at their definition site like so: {-# WARN_INSTANCE tuple #-} instance Foldable ((,) a) where ... {-# WARN_INSTANCE tuple #-} instance Functor ((,) a) where ... {-# WARN_INSTANCE tuple #-} instance Foldable ((,,) a b) where ... {-# WARN_INSTANCE tuple #-} instance Functor ((,,) a b) where ... This way, all the above instances are collected in an instance group labelled 'tuple'. At the use sites we introduce a GHC warning option like -fwarn-instance=tuple. This warns about any place where any of the 'tuple' instances is used. We can either place GHC-Options: -fwarn-instance=tuple in a Cabal package description in order to issue warnings in a whole package or we can put {-# OPTIONS_GHC -fwarn-instance=tuple #-} at the top of a module in order to enable the warning per module. Another candidate for an instance group might be 'numeric' for numeric instances of functions and tuples in the NumInstances package. What does it mean to use an instance? I would say, if omitting an instance X Y would lead to a "missing instance" type error at place Z in a module, then instance X Y is used at place Z. There might be an even more restrictive option like: -fforbid-instance=tuple This would not only warn about an instance usage, but it would cause a type error. Essentially it should treat all 'tuple' instances as if they were not defined. (Other instances might depend on 'tuple' instances and if the 'tuple' instances weren't there the compiler would not even reach the current module. I do not know, whether this case needs special treatment. We might require that any instance depending on 'tuple' must be added to the 'tuple' group as well or it might be added automatically.) The advantage of a type error is that we see all problems from 'tuple' instances also in the presence of other type errors. Warnings would only show up after a module is otherwise type correct. This solution requires cooperation of the instance implementor. Would that work in practice? Otherwise we must think about ways to declare instance groups independently from the instance declaration and we get the problem of bringing the instance group names into the scope of the importing module. A separate discussion must be held on whether -fwarn-instance=tuple should be part of -Wall. I think that people should be warned about 'tuple' instances early because they won't expect that there is a trap when using 'length' and 'maximum' and so on. One might also think about generalizations, e.g. whether {-# WARN_INSTANCE tuple, functor #-} should be allowed in order to put an instance in several groups or whether there should be a way to compose a group from subgroups. Another topic would be a form of instance group disambiguation. Instance groups might be qualified with module or package names. I think package names are more appropriate, like so: -fwarn-instance=base:tuple

1 0

idea: tool to suggest adding imports
by John Williams 20 Mar '16

20 Mar '16

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?

7 8

GHC 8.0.1 status
by Ben Gamari 01 Mar '16

01 Mar '16

tl;dr. Stabilizing the ghc-8.0 is taking a bit longer than was anticipated. The release schedule is being pushed back a bit. Hello everyone, As you likely know we are currently in the depths of the 8.0 release. In fact, under more ideal circumstances I would probably be cutting another release candidate right now instead of writing this email, in preparation for a final release next week or so. However, our world is far from ideal as evidenced by the number [1] of significant bugs present on the 8.0 branch. This isn't altogether unexpected; we knew we were taking a bit of a risk in merging so many high-impact patches in one release. However, we thought that given a longer-than-usual period between first-candidate and the final release, we'd have enough time to smooth out the wrinkles. Sadly, this has taken a bit longer than we anticipated. Of course, the last thing we want is to push a known buggy release out the door. Consequently, we won't be delivering the 8.0.1 release next week as originally planned. Instead, we'll be pushing the release back by about three weeks. This will give developers a bit more breathing room in which to work out the remaining issues. Hopefully in a few weeks the tree will be in such a state that we can push out yet another candidate which, with luck, will be the last before the release. If you'd like to expedite the process (and have fun in the process), you could do worse than to having a look at Trac [1], choosing a bug of your liking, and trying your hand at solving it. Thanks to everyone who has contributed to this effort thusfar. If you have any questions about the release process or how you can help, don't hesistate to ask. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1

3 4

[Feedback requested]: -fhelpful-import-errors
by Tom Sydney Kerckhove 16 Feb '16

16 Feb '16

Hi, 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 https://ghc.haskell.org/trac/ghc/wiki/Proposal/HelpfulImportError and am now looking for feedback. Thank you for your time. -- Tom Sydney Kerckhove

3 2

Reconsidering -Wall and -Wcompat
by Ben Gamari 15 Feb '16

15 Feb '16

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, https://docs.google.com/forms/d/1BmIQvhHcnDB79LgBvaWl_xXpS1q0dMHe3Gq9JeU9od… Feel free to discuss the issue further in this thread. Thank you for sharing, - Ben [1] https://mail.haskell.org/pipermail/ghc-devs/2015-October/010101.html [2] https://mail.haskell.org/pipermail/ghc-devs/2016-January/010955.html [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 4352 $ ls | wc -l 9347 [4] https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings/Wcompat

8 11