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