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 Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
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 > this case though it seems a bit odd in that using the code that uses > extensions also requires previously illegal syntax. But as long as > it's intentional it's fine by me. > > But is the bit where the calling module needs FlexibleConstraints also > intentional? It looks like it is. According to [1], the context must have the form `C a` unless FlexibleContexts is enabled. [1]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/other-type-extensions.html#flexible-contexts ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
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 development, but not outside it. For me, "during development" is when the author can see the output from the compiler. "Outside of it" is when the author is not looking at the output. When I'm developing, I want to see lots and lots of warnings. When I'm building something I downloaded from Hackage, I generally don't care. So I wonder if there's a way for the tooling to distinguish between development builds and non-dev builds. I know cabal better than stack, so I'll use that as my example. When I say `cabal configure --enable-tests; cabal build`, it means I want more information about how well this package works. Perhaps with --enable-tests, -Wall -Wcompat -Werror should be enabled by default. If I just say `cabal install`, I probably don't care so much about how well the package is working and can leave off the extra diagnostics. The approach of integrating this with tooling like cabal or stack also has the advantage that it is very easy to tailor custom treatment for specific compiler versions. This custom treatment could disable newly-written warnings individually if GHC introduces a new warning that, it is decided, should not be enabled by default on projects that wish to have legacy support. Would this address some of the problems that people have had in this space? Richard * By "interesting" here, I certainly don't mean "stupid". I mean "interesting", because I, like many people, tend to think that others think like I do. This is clearly not the case here, so I have to broaden my viewpoint. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
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 uses extensions also requires previously illegal syntax. But as long as it's intentional it's fine by me. But is the bit where the calling module needs FlexibleConstraints also intentional? On Mon, Feb 15, 2016 at 10:16 AM, Eric Seidel wrote: > 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. But I'm not familiar with > haskell-src-exts' internals, so that's just a wild guess :) > > FYI, as of RC2 we provide a type synonym > > type HasCallStack = (?callStack :: CallStack) > > in GHC.Stack, which is the recommended way to request a CallStack. We're > hiding the implicit parameter from the docs and API, as the reliance on > using the same name is a bit of a misfeature. We might also reimplement > HasCallStack without implicit-params in the future, so in the interest > of forward-compatibility I'd suggest using HasCallStack instead of your > own implicit-parameters. > > Eric > > > On Sun, Feb 14, 2016, at 16:32, Evan Laforge wrote: >> 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 :: Log.Stack => IO () >> f = Log.warn "blah blah" >> >> I noticed that now haskell-src-exts refuses to parse this file, saying >> 'MultiParamTypeClasses language extension is not enabled.'. >> >> I assume it's a bug with haskell-src-exts in that it should require >> LANGUAGE ConstraintKinds instead, but then GHC itself doesn't want >> ConstraintKinds. Instead, it wants FlexibleContexts. From the docs, >> FlexibleContexts seems to be about the contexts in instance heads. >> >> Is this intentional? I'll go ahead and make a bug for >> haskell-src-exts, but the ghc behaviour here seems odd as well. What >> extension should haskell-src-exts require to parse this? >> ___ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
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. But I'm not familiar with haskell-src-exts' internals, so that's just a wild guess :) FYI, as of RC2 we provide a type synonym type HasCallStack = (?callStack :: CallStack) in GHC.Stack, which is the recommended way to request a CallStack. We're hiding the implicit parameter from the docs and API, as the reliance on using the same name is a bit of a misfeature. We might also reimplement HasCallStack without implicit-params in the future, so in the interest of forward-compatibility I'd suggest using HasCallStack instead of your own implicit-parameters. Eric On Sun, Feb 14, 2016, at 16:32, Evan Laforge wrote: > 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 :: Log.Stack => IO () > f = Log.warn "blah blah" > > I noticed that now haskell-src-exts refuses to parse this file, saying > 'MultiParamTypeClasses language extension is not enabled.'. > > I assume it's a bug with haskell-src-exts in that it should require > LANGUAGE ConstraintKinds instead, but then GHC itself doesn't want > ConstraintKinds. Instead, it wants FlexibleContexts. From the docs, > FlexibleContexts seems to be about the contexts in instance heads. > > Is this intentional? I'll go ahead and make a bug for > haskell-src-exts, but the ghc behaviour here seems odd as well. What > extension should haskell-src-exts require to parse this? > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
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 :: Log.Stack => IO () f = Log.warn "blah blah" I noticed that now haskell-src-exts refuses to parse this file, saying 'MultiParamTypeClasses language extension is not enabled.'. I assume it's a bug with haskell-src-exts in that it should require LANGUAGE ConstraintKinds instead, but then GHC itself doesn't want ConstraintKinds. Instead, it wants FlexibleContexts. From the docs, FlexibleContexts seems to be about the contexts in instance heads. Is this intentional? I'll go ahead and make a bug for haskell-src-exts, but the ghc behaviour here seems odd as well. What extension should haskell-src-exts require to parse this? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
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. 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_xXpS1q0dMHe3Gq9JeU9odM/viewform > > 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 > ___ > ghc-devs mailing list > ghc-d...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
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 desired;”. The sometimes complicated hoops that you will have to jump through to gain 3-release-backward-compatibility are not something I expect every developer to follow, and for most others, “adjust early to API changes” will more likely be the sensible thing to do. Those might want to leave -Wcompat in their builds. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
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 fraction of GHC's warning collectionand is is intended [2] > for use during development. > IMHO, the distinction between "during development" and "outside of it" is purely hypothetical. A typical workflow is: Develop your code locally against one GHC/set of libraries, commit to GitHub and let Travis CI do the real work of testing against a matrix of configurations. If things work well and the changes are worth it, tag your current state and release it. Where exactly in this scenario is the code leaving the "during development" state? I definitely want to enable -Wall for the Travis CI builds, because that's the place where they are most valuable. As stated on the Wiki, stuff in -Wcompat will often be non-actionable, so the only option I see if -Wcompat is included in -Wall will be -Wno-compat for all my projects. -Wcompat would be restricted to a few manual local builds to see where things are heading. > 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, [...] Seeing -Wall this way is quite unusual, especially for people coming from C/C++ (and the numbers quoted from Hackage seem to be a hint that others think so, too). Normally, -Wall -Wextra -pedantic etc. are life-savers and should be kept enabled all the time, unless you like endless debugging hours, of course. In a nutshell: I would consider -Wall implying -Wcompat an annoyance, but as long as it can be disabled by 2 lines in .travis.yml, I don't really care. ;-) Cheers, S. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reconsidering -Wall and -Wcompat
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_xXpS1q0dMHe3Gq9JeU9odM/viewform 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 signature.asc Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
