Please review: #454 Custom type warnings
Hi all, As Joachim noted, #454 <https://github.com/ghc-proposals/ghc-proposals/pull/454> is extracted from Adam’s previous efforts with the Unsatisfiable constraint <https://github.com/ghc-proposals/ghc-proposals/pull/433> 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
I vote to accept. Thanks, Richard
On Jan 13, 2022, at 11:19 AM, Tom Harding <i.am.tom.harding@gmail.com> wrote:
Hi all,
As Joachim noted, #454 <https://github.com/ghc-proposals/ghc-proposals/pull/454> is extracted from Adam’s previous efforts with the Unsatisfiable constraint <https://github.com/ghc-proposals/ghc-proposals/pull/433> 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
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@richarde.dev> wrote:
I vote to accept.
Thanks, Richard
On Jan 13, 2022, at 11:19 AM, Tom Harding <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 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
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 <lists@richarde.dev> wrote:
I vote to accept.
Thanks, Richard
On Jan 13, 2022, at 11:19 AM, Tom Harding <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 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 <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) < 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 <lists@richarde.dev> wrote:
I vote to accept.
Thanks, Richard
On Jan 13, 2022, at 11:19 AM, Tom Harding <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
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
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@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@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@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@richarde.dev> wrote:
I vote to accept.
Thanks, Richard
On Jan 13, 2022, at 11:19 AM, Tom Harding <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
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 <arnaud.spiwack@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@tweag.io <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 <lists@richarde.dev <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) <vlad.z.4096@gmail.com <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 <lists@richarde.dev <mailto:lists@richarde.dev>> wrote:
I vote to accept.
Thanks, Richard
On Jan 13, 2022, at 11:19 AM, Tom Harding <i.am.tom.harding@gmail.com <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, Deep Subsumption has been submitted by Matthew Pickering, Simon Peyton Jones and Jaro Reinders https://github.com/ghc-proposals/ghc-proposals/pull/511 https://github.com/mpickering/ghc-proposals/blob/deep-subsumption/proposals/... Given that this refines #281, shepherded by Arnaud, I suggest that he shepherds this one too. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim
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/
I've added some technical comments. I'm not terribly enthusiastic (one more thing to implement and maintain) but neither am I against. I can see the attraction. Simon On Thu, 13 Jan 2022 at 16:19, Tom Harding <i.am.tom.harding@gmail.com> wrote:
Hi all,
As Joachim noted, #454 <https://github.com/ghc-proposals/ghc-proposals/pull/454> is extracted from Adam’s previous efforts with the Unsatisfiable constraint <https://github.com/ghc-proposals/ghc-proposals/pull/433> 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
participants (6)
-
Joachim Breitner -
Richard Eisenberg -
Simon Peyton Jones -
Spiwack, Arnaud -
Tom Harding -
Vladislav Zavialov (int-index)