October 2020 - Glasgow-haskell-users

[ANNOUNCE] Glasgow Haskell Compiler 9.0.1-alpha1 released
by Ben Gamari 06 Dec '20

06 Dec '20

Hello all, The GHC team is very pleased to announce the availability of the first alpha release in the GHC 9.0 series. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/9.0.1-alpha1/ This first alpha comes quite a bit later than expected. However, we have done a significant amount of testing on this pre-release and therefore hope to be able to move forward quickly with a release candidate next week and with a final release in mid-October. GHC 9.0.1 will bring a number of new features: * A first cut of the new LinearTypes language extension [1], allowing use of linear function syntax and linear record fields. * A new bignum library (ghc-bignum), allowing GHC to be more easily used with integer libraries other than GMP. * Improvements in code generation, resulting in considerable performance improvements in some programs. * Improvements in pattern-match checking, allowing more precise detection of redundant cases and reduced compilation time. * Implementation of the "simplified subsumption" proposal [2] simplifying the type system and paving the way for QuickLook impredicativity in GHC 9.2. * Implementation of the QualifiedDo extension [3], allowing more convenient overloading of `do` syntax. * Improvements in compilation time. And many more. See the release notes [4] for a full accounting of the changes in this release. Do note that there are a few things that we expect will change before the final release: * We expect to sort out a notarization workflow for Apple Darwin, allowing our binary distributions to be used on macOS Catalina without hassle. Until this has been sorted out Catalina users can exempt the current macOS binary distribution from the notarization requirement themselves by running `xattr -cr .` on the unpacked tree before running `make install`. * We will likely transition the Alpine binary distribution to be fully statically-linked, providing a convenient, distribution-independent packaging option for Linux users. * We will be merging a robust solution for #17760 which will introduce a new primitive, `keepAlive#`, to the `base` library, subsuming most uses of `touch#`. As always, do test this release and open tickets for whatever issues you encounter. To help with this, we will be publishing a blog post describing use of our new `head.hackage` infrastructure to ease testing of larger projects with Hackage dependencies later this week. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-l… [2] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-s… [3] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-q… [4] https://downloads.haskell.org/ghc/9.0.1-alpha1/docs/html/users_guide/9.0.1-…

4 4

Language extension histories
by David Feuer 31 Oct '20

31 Oct '20

I'm working on some code I want to be compatible with multiple GHC versions and I'm trying to figure out which language extensions I can reasonably use. I definitely need usable fancy pattern synonyms (not the bare-bones ones in 7.8). So that should set a lower bound, but I don't remember where. 7.10? 8.0? I'd also *like* to use an injective type family, but I can work around that pretty easily with a data family if necessary. When did PatternSynonyms and TypeFamilyDependencies each become reasonably usable?

3 4

"... causes overflow in R_X86_... relocation"
by Volker Wysk 17 Oct '20

17 Oct '20

Hi. I have a litte program named "svumb", which compiles and links without error or warning message. But when I start it, this happens: build/svumb: Symbol `qtahzmqt5zm0zi7zi0zm4ATcbzzMngNWCbnemaqWUdM_GraphicsziUIziQtahziGeneratedziWidgetsziQMessageBox_setText_closure' causes overflow in R_X86_64_32 relocation (... long list of similar messages ...) build/svumb: Symbol `stg_INTLIKE_closure' causes overflow in R_X86_64_32 relocation build/svumb: error while loading shared libraries: unexpected reloc type 0x0b Do those messages make sense to anyone? What is a "R_X86_64_32 relocation"? What is a "reloc type"? What's happening?? Calling "sudo ldconfig" doesn't help. The program uses the Qtah package, which is a Qt binding for Haskell. It might have something to do with this. It can't be linked statically, because then the following error occurs after starting the compiled and linked program: .../build/svumb: error while loading shared libraries: libqtah.so.0: cannot open shared object file: No such file or directory Compiling it dynamically had worked, but now I have the problem above. Regards, Volker

2 2