[ghc-steering-committee] #390: Fine-grained pragmas, recommendation: accept

Vitaly Bragilevsky bravit111 at gmail.com
Sat Sep 18 09:46:49 UTC 2021


Hi Joachim,

Simon PJ had several suggestions here:
https://github.com/ghc-proposals/ghc-proposals/pull/390#issuecomment-889025857.
I believe it's up to Alejandro to either address them in the proposal or
decline.

Vitaly



вт, 14 сент. 2021 г. в 10:47, Joachim Breitner <mail at joachim-breitner.de>:

> Hi Vitaly,
>
> what is the status of this? Richard said he supports acceptance, but I
> am not sure if there are still open questions?
>
> Cheers,
> Joachim
>
> Am Freitag, dem 23.07.2021 um 07:44 +0000 schrieb Alejandro Serrano
> Mena:
> >  Dear all,
> > I’ve just updated the proposal following a great suggestion by Vlad.
> >
> > Unfortunately, I don’t know enough about GHC’s parsing machinery to
> > answer the question posed by Richard. I’ll repeat it in case somebody
> > in the Committee can shed some light on it:
> >
> > > The proposal use ; to separate the modifiers from the declarations.
> > > Combined with the layout rule this allows us to write in two forms:
> > >
> > >
> > >
> > >  > %NoTerminationCheck ; instance C Int where ...
> > >
> > >
> > > > %NoTerminationCheck
> > > > instance C Int where …
> > >
> > > Would it be possible to allow the modifier to simply precede the
> > > `instance` without turning the parser into a mess?
> > >
> >
> > Regards,
> > Alejandro
> >
> > El 12 jul 2021 15:52:01, Richard Eisenberg <lists at richarde.dev>
> > escribió:
> >
> > > I'm happy with this updated proposal, though I've made a small
> > > suggestion about making the ;s optional.
> > >
> > > Regardless of whether this suggestion is taken, I support
> > > acceptance.
> > >
> > > Thanks,
> > > Richard
> > >
> > > > On Jul 4, 2021, at 5:12 AM, Vitaly Bragilevsky
> > > > <bravit111 at gmail.com> wrote:
> > > >
> > > > Dear Committee,
> > > >
> > > > I'm happy to repeat my recommendation to accept Alejandro's
> > > > proposal which is now back from revision:
> > > > Fine-grained pragmas for classes, families, and instances
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/390
> > > >
> https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md
> > > >
> > > > All the issues that arose in the previous discussion are now
> > > > resolved. Does anyone have something to add?
> > > >
> > > > Vitaly
> > > >
> > > >
> > > >
> > > > сб, 13 мар. 2021 г. в 12:38, Vitaly Bragilevsky
> > > > <bravit111 at gmail.com>:
> > > > > чт, 11 мар. 2021 г. в 16:31, Vladislav Zavialov (int-index)
> > > > > <vlad.z.4096 at gmail.com>:
> > > > > > I like the proposal and I would be happy to vote for its
> > > > > > acceptance. However, it requires a little bit of polishing up
> > > > > > with regards to its use of modifiers. In particular, it seems
> > > > > > to treat modifiers as built-in units, whereas the core idea
> > > > > > behind modifiers is that they are based on actual promoted
> > > > > > types (with the exception of %1).
> > > > > >
> > > > > > Hence it seems appropriate to send it back for revision until
> > > > > > this point is addressed.
> > > > > >
> > > > >
> > > > >
> > > > > Yes, I agree. There is also another issue. I think we need
> > > > > either a deprecation story for UndecidableInstances, or a
> > > > > statement that it should survive with some motivation behind
> > > > > that.
> > > > >
> > > > > So, I'm sending this proposal back to Alejandro for review and
> > > > > set the "needs revision" label on GitHub.
> > > > >
> > > > > Vitaly
> > > > > >
> > > > > > - Vlad
> > > > > >
> > > > > > > On 20 Feb 2021, at 14:34, Vitaly Bragilevsky
> > > > > > <bravit111 at gmail.com> wrote:
> > > > > > >
> > > > > > > Dear Committee,
> > > > > > >
> > > > > > > Our own Alejandro has been proposed
> > > > > > > Fine-grained pragmas for classes, families, and instances
> > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/390
> > > > > > >
> > > > > >
> https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md
> > > > > > >
> > > > > > > His idea is to bring the flexibility of
> > > > > > overlaps/overlapping/overlappable pragmas to termination
> > > > > > checking, type inference, and constraint solving. Alejandro
> > > > > > proposes to introduce the following %-modifiers (as in
> > > > > > already
> > > > > > accepted #370,
> > > > > >
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0370-modifiers.rst
> > > > > > ):
> > > > > > > %NoTerminationCheck
> > > > > > > %LiberalCoverage
> > > > > > > %LiberalInjectivity
> > > > > > > %Overlapping
> > > > > > > %Overlappable
> > > > > > > %Overlaps
> > > > > > > to liberate conditions for classes and instances, type
> > > > > > families, forall-types, etc. The first three modifiers can be
> > > > > > used instead of the scary-sounding UndecidableInstances
> > > > > > extension. The last three modifiers are supposed to be used
> > > > > > instead of the  overlap*-pragmas for instances we already
> > > > > > have.
> > > > > > Note that this proposal doesn't suggest deprecating those
> > > > > > extensions and pragmas.
> > > > > > >
> > > > > > > I think that this proposal goes in the right direction and
> > > > > > recommend accepting it.
> > > > > > >
> > > > > > > As far as I understand, all the committee members,
> > > > > > > including
> > > > > > those with terms about to expire, have the right to either
> > > > > > support this proposal or to raise a voice against it either
> > > > > > here or at
> > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/390.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Vitaly
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > ghc-steering-committee mailing list
> > > > > > > ghc-steering-committee at haskell.org
> > > > > > >
> > > > > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > > >
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > >
> > >  _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> 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/20210918/29f5aba6/attachment.html>


More information about the ghc-steering-committee mailing list