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

[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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210723/13af6efc/attachment.html>