Re: LANGUAGE ConstraintKinds not needed to use ConstraintKinds?

On Mon, Feb 15, 2016 at 12:57 PM, Eric Seidel wrote: > It looks like it is. According to [1], the context must have the form `C > a` unless FlexibleContexts is enabled. Works for me, thanks! ___ Glasgow-haskell-users mailing list

Re: LANGUAGE ConstraintKinds not needed to use ConstraintKinds?

On Sun, Feb 14, 2016, at 18:15, Evan Laforge wrote: > Right, that sounds like a good idea to me, it's the same reason I > added the synonym myself. > > WRT not needing an extension I guess this is part of a general pattern > where you don't need extensions to use code that uses extensions. In >

Re: Reconsidering -Wall and -Wcompat

On Feb 14, 2016, at 1:51 PM, Sven Panne wrote: > > IMHO, the distinction between "during development" and "outside of it" is > purely hypothetical. I find this comment quite interesting, as I see quite a large difference between these.* For example, I use -Werror during

Re: LANGUAGE ConstraintKinds not needed to use ConstraintKinds?

Right, that sounds like a good idea to me, it's the same reason I added the synonym myself. WRT not needing an extension I guess this is part of a general pattern where you don't need extensions to use code that uses extensions. In this case though it seems a bit odd in that using the code that

Re: LANGUAGE ConstraintKinds not needed to use ConstraintKinds?

IIRC ConstraintKinds is only required in the module that defines the type synonym, so your module T does not need it. My guess is that haskell-src-exts sees 'Log.Stack =>', in which we have nullary constraint instead of a unary constraint, and assumes that's bogus without MultiParamTypeClasses.

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 ::

Re: Reconsidering -Wall and -Wcompat

[Deliberately restricting my reply to one mailing list. Cross-posting is usually not required.] Hi, Am Sonntag, den 14.02.2016, 19:51 +0100 schrieb Sven Panne: > As stated on the Wiki, stuff in -Wcompat will often be non- > actionable, you omitted the important “if backwards compatibility is

Re: Reconsidering -Wall and -Wcompat

Just as one data point, the Swift compiler is by default showing warnings about upcoming changes. Just like deprecation warnings, I do find that helpful. Based on that experience, including -Wcompat in -Wall seems like a good plan to me. Manuel > Ben Gamari : > > tl;dr.

Re: Reconsidering -Wall and -Wcompat

2016-02-14 17:12 GMT+01:00 Ben Gamari : > [...] 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