- Glasgow-haskell-users

[ANNOUNCE] Glasgow Haskell Compiler 8.0.2 is available!
by Ben Gamari 19 Jan '17

19 Jan '17

=============================================== The Glasgow Haskell Compiler -- version 8.0.2 =============================================== The GHC team is happy to at last announce the 8.0.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at http://downloads.haskell.org/~ghc/8.0.2/ This is the second release of the 8.0 series and fixes nearly two-hundred bugs. These include, * Interface file build determinism (#4012). * Compatibility with macOS Sierra and GCC compilers which compile position-independent executables by default * Compatibility with systems which use the gold linker * Runtime linker fixes on Windows (see #12797) * A compiler bug which resulted in undefined reference errors while compiling some packages (see #12076) * A number of memory consistency bugs in the runtime system * A number of efficiency issues in the threaded runtime which manifest on larger core counts and large numbers of bound threads. * A typechecker bug which caused some programs using -XDefaultSignatures to be incorrectly accepted. * More than two-hundred other bugs. See Trac [1] for a complete listing. * #12757, which lead to broken runtime behavior and even crashes in the presence of primitive strings. * #12844, a type inference issue affecting partial type signatures. * A bump of the `directory` library, fixing buggy path canonicalization behavior (#12894). Unfortunately this required a major version bump in `directory` and minor bumps in several other libraries. * #12912, where use of the `select` system call would lead to runtime system failures with large numbers of open file handles. * #10635, wherein -Wredundant-constraints was included in the -Wall warning set A more detailed list of the changes included in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/8.0.2-notes.… Please note that this release breaks with our usual tendency to avoid major version bumps of core libraries in minor GHC releases by including an upgrade of the `directory` library to 1.3.0.0. Also note that, due to a rather serious bug (#13100) affecting Windows noticed late in the release cycle, the Windows binary distributions were produced using a slightly patched [2] source tree. Users compiling from source for Windows should be certain to include this patch in their build. This release is the result of six months of effort by the GHC development community. We'd like to thank everyone who has contributed code, bug reports, and feedback to this release. It's only due to their efforts that GHC remains a vibrant and exciting project. [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.0.2&col=id… [2] http://downloads.haskell.org/~ghc/8.0.2/0001-SysTools-Revert-linker-flags-c… How to get it ~~~~~~~~~~~~~ Both the source tarball and binary distributions for a wide variety of platforms are available at, http://www.haskell.org/ghc/ Background ~~~~~~~~~~ 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 http://ghc.haskell.org/trac/ghc/wiki/Platforms Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on getting started with hacking on GHC are available from GHC's developer site, http://ghc.haskell.org/trac/ghc/ Community Resources ~~~~~~~~~~~~~~~~~~~ There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other Haskell and GHC-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

2 2

Re: Rewrite rules
by David Feuer 16 Jan '17

16 Jan '17

No. The part in quotes is the *name* of the rewrite rule, which is reported to the user when GHC is called with things like -ddump-rule-rewrites and is otherwise completely ignored. On Jan 16, 2017 4:09 AM, "Erik de Castro Lopo" <mle+hs(a)mega-nerd.com> wrote: Joachim Breitner wrote: > very little. The best one can do right now is to know enough about Core > and the inliner to predict when things are going to be inlined and when > not, what else can go wrong (wrappers maybe?), add the necessary > controls (`NOINLINE [0]` etc.), and then hope for the best. And track > down any instances of failed rewriting that you learn about. > > You might also be able to set up your code so that it fails (at > runtime, with error) if the desired rules did not fire. This would be > nicer if we had https://ghc.haskell.org/trac/ghc/ticket/9180. > > You can also ask for review if it is public code. Ok, I'm heading in this direction and then I figure out that the parser for the rewrite rules doesn't even reject obvious syntax errors. Say I have a data types: data Word128 = Word128 Word64 Word64 and inspired by the `fromIntegral` rules for Word64 I write: {-# RULES "fromIntegral/Word64->Word128" fromIntegral = \w64 -> Word128 0 w64 #-} all is fine and dandy. However if I introduce an obvious syntax error like reversing the `->`: {-# RULES "fromIntegral/Word64<-Word128" fromIntegral = \w64 -> Word128 0 w64 #-} I don't get any warning or anything. I've read the docs for rewrite rules: https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_ guide/glasgow_exts.html#rewrite-rules but they are rather sparse and again are very short on guarantees. Have I just managed to find myself a new project? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

1 0

Rewrite rules
by Erik de Castro Lopo 16 Jan '17

16 Jan '17

HI all, I'm having an look at rewrite rules, but something bugs me a little. How do I tell if my rewrite rules are firing or not? Even If I introduce deliberate errors in the function name that is being re-written I still don't get so much as a warning. Clues? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

3 4

Re: Derived Functor instance for void types
by Edward Kmett 16 Jan '17

16 Jan '17

"Preserving user bottoms" was found to be better behavior for us with Void as well back in the day. Evaluating such a term to get the bottom out is better than making up one that loses information for the user about precisely what bottom it is they had. We do so with absurd and the like for Void. This way if you map over a structure with errors at the leaves you get a new structure with those same errors at the leaves. *tl;dr* +1 from me. -Edward On Sun, Jan 15, 2017 at 11:00 PM, Kevin Cotrone <kevincotrone(a)gmail.com> wrote: > That seems to have a surprising strictness. > > I'm not sure if it would be the best idea to try and evaluate a type with > no inhabitants. > > On Sun, Jan 15, 2017 at 2:37 PM, David Feuer <david.feuer(a)gmail.com> > wrote: > >> Currently, if you write >> >> data V a deriving Functor >> >> GHC generates >> >> fmap _ _ = error "Void fmap" >> >> This seems quite unfortunate, because it loses potentially useful error >> information: >> >> fmap (+ 3) (error "Too many snozzcumbers!") >> >> throws "Void fmap", rather than the much more precise "Too many >> snozzcumbers!" I've opened Trac #13117 to fix this, but I figured I should >> double check that no one is opposed. >> >> David Feuer >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >

1 0

Re: Derived Functor instance for void types
by David Feuer 16 Jan '17

16 Jan '17

I don't know what you mean. fmap for an uninhabited type is vacuously strict: its result is always _|_. On Sun, Jan 15, 2017 at 11:00 PM, Kevin Cotrone <kevincotrone(a)gmail.com> wrote: > That seems to have a surprising strictness. > > I'm not sure if it would be the best idea to try and evaluate a type with no > inhabitants. > > On Sun, Jan 15, 2017 at 2:37 PM, David Feuer <david.feuer(a)gmail.com> wrote: >> >> Currently, if you write >> >> data V a deriving Functor >> >> GHC generates >> >> fmap _ _ = error "Void fmap" >> >> This seems quite unfortunate, because it loses potentially useful error >> information: >> >> fmap (+ 3) (error "Too many snozzcumbers!") >> >> throws "Void fmap", rather than the much more precise "Too many >> snozzcumbers!" I've opened Trac #13117 to fix this, but I figured I should >> double check that no one is opposed. >> >> David Feuer >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >

1 0

Derived Functor instance for void types
by David Feuer 15 Jan '17

15 Jan '17

Currently, if you write data V a deriving Functor GHC generates fmap _ _ = error "Void fmap" This seems quite unfortunate, because it loses potentially useful error information: fmap (+ 3) (error "Too many snozzcumbers!") throws "Void fmap", rather than the much more precise "Too many snozzcumbers!" I've opened Trac #13117 to fix this, but I figured I should double check that no one is opposed. David Feuer

1 0

Narrower (per-method) GND
by David Feuer 12 Jan '17

12 Jan '17

There are some situations where we may want to use GND to derive some class methods when it's not applicable to others. For example, some people would very much like to add a join method to Monad, but doing so would prevent GND from working for Monad. Similarly, the distribute method of Data.Distributive.Distributive is incompatible with GND. In each of these cases, a perfectly valid, and efficient, way to derive the class would be to use the GND mechanism to derive the methods it works with and the default method definitions for the rest. To cover these cases, I think it would be nice to allow a method declaration to give a default definition intended to be used for GND. This may or may not be the same as the usual default. Some classes can support GND for some methods, but using defaults for the others would give poor implementations. To cover this case, I think it would be nice to add per-method GND-deriving syntax. This could look something like instance C T where deriving f g = ....

5 9

GHC rewrite rules for class operations & laws
by Conal Elliott 04 Jan '17

04 Jan '17

Is it possible to apply GHC rewrite rules to class methods? From what I’ve read and seen, class methods get eliminated early by automatically-generated rules. Is there really no way to postpone such inlining until a later simplifier stage? The GHC Users Guide docs say no <https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext…>, and suggests instead giving a duplicate vocabulary with somewhat awkward names for class methods. I’ve not seen this practice in libraries. I gather that we cannot therefore use class laws as optimizations in the form of rewrite rules, which seems a terrible loss. In Control.Category and Control.Arrow, I see rules for class laws but also header comments saying “The RULES for the methods of class Arrow may never fire e.g. compose/arr; see Trac #10528”. I’d appreciate a reality check about my conclusions as well as any strategies for using class laws in optimization. Thanks, -- Conal

5 9

[ANNOUNCE] Formation of the initial GHC Steering Committee
by Ben Gamari 04 Jan '17

04 Jan '17

Dear Haskell community, Over the past months we have discussed changes to GHC's process for collecting, discussing, and considering new language extensions, compiler features, and the like. Happily, we are now ready to move forward with our new proposal process. Towards this end, we have formed the GHC Steering Committee which will be responsible for evaluating the proposals that run through the process. The committee consists of the following members (with GitHub user names given parenthetically), * Chris Allen (@bitemyapp) * Joachim Breitner (@nomeata) * Manuel M T Chakravarty (@mchakravarty) * Iavor Diatchki (@yav) * Atze Dijkstra (@atzedijkstra) * Richard Eisenberg (@goldfirere) * Ben Gamari (@bgamari) * Simon Marlow (@simonmar) * Ryan Newton (@rrnewton) * Simon Peyton-Jones (@simonpj) The body will be chaired jointly by Simon Marlow and Simon Peyton-Jones. Since the ghc-proposals repository was created, it has accumulated nearly thirty pull requests describing a variety of compelling changes. We will consider these proposals to be at the beginning of their four-week discussion period. The goal of this discussion is to find and eliminate weaknesses of the proposal. The final proposal should address all valid points raised in the discussion. When you believe the proposal has converged, bring it to the steering committee and summarize the discussion in a pull request comment. If you would like to contribute a new proposal, please refer to the directions given in the ghc-proposals' repository README [1] and proposal submission guidelines [2]. Cheers, - Ben, on behalf of the GHC Steering Committee [1] https://github.com/ghc-proposals/ghc-proposals [2] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposal-submiss…

1 0

[ANNOUNCE] GHC 8.0.2 release candidate 2
by Ben Gamari 28 Dec '16

28 Dec '16

Hello everyone, The GHC team is happy to announce the second candiate of the 8.0.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at http://downloads.haskell.org/~ghc/8.0.2-rc2/ This is the second and likely final release candidate leading up the 8.0.2 release. This release will fix a number of bugs found in 8.0.1 including, * Interface file build determinism (#4012). * Compatibility with macOS Sierra and GCC compilers which compile position-independent executables by default * Runtime linker fixes on Windows (see #12797) * A compiler bug which resulted in undefined reference errors while compiling some packages (see #12076) * Compatability with systems which use the gold linker * A number of memory consistency bugs in the runtime system * A number of efficiency issues in the threaded runtime which manifest on larger core counts and large numbers of bound threads. * A typechecker bug which caused some programs using -XDefaultSignatures to be incorrectly accepted. * More than two-hundred other bugs. See Trac [1] for a complete listing. This release candidate fixes a number of issues present in -rc1, * #12757, which lead to broken runtime behavior and even crashes in the presence of primitive strings. * #12844, a type inference issue affecting partial type signatures. * A bump of the `directory` library, fixing buggy path canonicalization behavior (#12894). Unfortunately this required a major version bump in `directory` and minor bumps in several other libraries. * #12912, where use of the `select` system call would lead to runtime system failures with large numbers of open file handles. If all goes well we should have a final 8.0.2 release out shortly after the new year. As always, let us know if you encounter trouble. Thanks to everyone who has contributed so far! Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.0.2&col=id…

3 3