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

I vote to accept.

Thanks, Richard

...

On Jan 13, 2022, at 11:19 AM, Tom Harding 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I realise that I hadn't opined here. I'm in favour. On Thu, Jan 13, 2022 at 11:51 PM Richard Eisenberg 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@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 wrote:

I vote to accept.

Thanks, Richard

...

On Jan 13, 2022, at 11:19 AM, Tom Harding 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@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I'm in favor of acceptance.

On Jun 1, 2022, at 5:54 AM, Spiwack, Arnaud 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 mailto:arnaud.spiwack@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 mailto:lists@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) mailto:vlad.z.4096@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 mailto:lists@richarde.dev> wrote:

I vote to accept.

Thanks, Richard

...

On Jan 13, 2022, at 11:19 AM, Tom Harding mailto:i.am.tom.harding@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Dear Committee, Decorate exceptions with backtrace information has been submitted by Ben Gamari; David Eichmann; Sven Tennie https://github.com/ghc-proposals/ghc-proposals/pull/330 https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exc... I’d like to ask Vlad to shepherd this. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/