Re: Warning suppression pragmas

This proposal is a good start, but it needs more fleshing out. - What scopes are allowed to suppress over? For example, is it possible to suppress warnings for scopes other than a function (for example, within a case expression)? What about type declarations? Local declarations? In a type

Re: Performance of pattern checker on OptCoercions

On Dec 13, 2015, at 1:07 PM, George Karachalias wrote: > Sounds nice and I think it is much better than giving up guards completely. > The only thing I > don't like much is having so many different flags concerning the check > because I don't want > it to become

GHC 8.0 feature freeze imminent

Hello GHCers, Last Friday Richard Eisenberg's long-awaited no-kinds branch landed in `master`. Being one of the defining features of the 8.0 release, we bent the feature freeze schedule (initially slated for sometime last week) a bit to accomodate this piece of work. Now that Richard's work is

Re: Warning suppression pragmas

Hi devs! I edited wiki page [1] with my proposal about more than week ago. The main idea is that we mark functins with pragma and filter all warnings that it will throw. Although it is the question of bad design, i think users, who have to support old libraries will find this helpful. I don't

Re: GHC 8.0 feature freeze imminent

One thing I definitely want to get in before the 8.0 release is: * A fix for Trac #10716 [1] (adding strictness metadata to GHC generics). This feels like a natural counterpart for Trac #10697 [2] (reworking strictness information to Template Haskell), which currently has a Phab Diff in review

Re: Questions concerning the LLVM backend - i.e. 'proc point splitting'

Simon > | Could you explain the need of further info-tables for 'inner' > | proc-points (those, which are not the entry-block of a function) to > | me, please? > > The main purpose of inner info tables is this. Given (case e of blah) we > push a return address (for 'blah') on the stack and

Re: GHC 8.0 feature freeze imminent

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14.12.2015 14:38, Ben Gamari wrote: > If you have work still outstanding then you should talk to either me or > Austin ASAP if you have not done so already. The addition of the -W warning syntax [1] is on its way [2]. Unfortunatly, the -

Re: GHC 8.0 feature freeze imminent

I would love to land my fix for #10828, but now that the wildcard refactor and no-kinds have been merged it will require a substantial rewrite. I'll try to do that on Wednesday and hopefully there will be enough time for a review before feature freeze. Janek --- Politechnika Łódzka Lodz

RE: -XStrict: Why some binders are not made strict?

| Given the upcoming 8.0 feature freeze I think the correct approach for | 8.0 is to document the current implementation (I'll try to do that this | week). Yes, that's right. Thanks! Simon | | It would probably be good if interested parties would document their | input in a ticket. | |

Re: GHC 8.0 feature freeze imminent

Ryan Scott writes: > One thing I definitely want to get in before the 8.0 release is: > > * A fix for Trac #10716 [1] (adding strictness metadata to GHC > generics). This feels like a natural counterpart for Trac #10697 [2] > (reworking strictness information to Template

Re: -XStrict: Why some binders are not made strict?

Hello, Given the upcoming 8.0 feature freeze I think the correct approach for 8.0 is to document the current implementation (I'll try to do that this week). It would probably be good if interested parties would document their input in a ticket. Cheers, --Adam On Sat, 12 Dec 2015, at 12:55 AM,

Re: -XStrict: Why some binders are not made strict?

Agreed. (Sorry for the sporadic communication. This is a very busy time at work.) I thought about this a bit more recently. Here's one way where I think "force every binder" goes wrong: -- In a Strict module f (Just x) = Just x This is not the identity. This might matter in practice if a user