[ghc-steering-committee] Please review: #454 Custom type warnings

Richard Eisenberg lists at richarde.dev
Wed Jun 1 16:25:02 UTC 2022


I'm in favor of acceptance.

> On Jun 1, 2022, at 5:54 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> Dear all,
> 
> I think that the objections raised so far were very minor. And the proposal is well justified. It's not a big enough proposal that we should weigh our options carefully for too long. I propose we accept promptly.
> 
> On Wed, Mar 30, 2022 at 10:20 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> I realise that I hadn't opined here.
> 
> I'm in favour.
> 
> On Thu, Jan 13, 2022 at 11:51 PM Richard Eisenberg <lists at richarde.dev <mailto:lists at richarde.dev>> wrote:
> That's a really good point. Do you want to raise it on the PR?
> 
> Richard
> 
> > On Jan 13, 2022, at 4:56 PM, Vladislav Zavialov (int-index) <vlad.z.4096 at gmail.com <mailto:vlad.z.4096 at gmail.com>> wrote:
> > 
> > Can we guarantee erasure? Is `Warning flag msg => t` the same operationally as just `t`?
> > 
> > The proposal does not say that. And it’s not what I would’ve expected from a constraint. Yet it’s something I expect from a warning.
> > 
> > I am not comfortable with a design where adding a custom warning, the purpose of which is to improve developer experience, comes at a cost of potential performance regression.
> > 
> > This isn’t a trade off that users of GHC should be facing.
> > 
> > - Vlad
> > 
> >> On 14 Jan 2022, at 00:47, Richard Eisenberg <lists at richarde.dev <mailto:lists at richarde.dev>> wrote:
> >> 
> >> I vote to accept.
> >> 
> >> Thanks,
> >> Richard
> >> 
> >>> On Jan 13, 2022, at 11:19 AM, Tom Harding <i.am.tom.harding at gmail.com <mailto:i.am.tom.harding at gmail.com>> wrote:
> >>> 
> >>> Hi all,
> >>> 
> >>> As Joachim noted, #454 is extracted from Adam’s previous efforts with the Unsatisfiable constraint proposal (which has since been accepted). In short, it covers an interface for custom warnings, and I can already think of plenty of ways I’d use it. I’d therefore like to recommend acceptance, and discuss any issues or changes.
> >>> 
> >>> Thanks,
> >>> Tom
> >>> _______________________________________________
> >>> ghc-steering-committee mailing list
> >>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> >> 
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> > 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220601/50d5ac40/attachment.html>


More information about the ghc-steering-committee mailing list