<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">I think there is a debate to be had about whether modifiers are really <br>
the best approach in general. Is the lack of motivation to implement <br>
then a sign that we don't really need them
</div></blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">We can always re-open an <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0370-modifiers.rst">accepted proposal</a>, especially if it is not yet implemented!</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">The motivations for modifiers I see are:</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><ul><li>We have modifiers for linear types</li><li>It seem wrong to use pragmas (in {-# #-} comments) for things that are semantically meaningful like overlapping instances.</li></ul><div>We definitely want modifiers <b>in some form</b>. We currently use them a lot for {-# OVERLAPPABLE #-} etc. We <b>could </b>stick with the {-# prag #-} syntax. But it's a bit noisy, and it really isn't a comment. And (unlike the modifier) the pragma stuff doesn't have internal structure -- we could not use it for linear annotations.</div><div><br></div><div>But I think we should decide what syntax we want for modifier-like things, and get it implemented, else it'll keep blocking other proposals, like this one from Matthew.</div><div><br></div><div>Simon<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 9 Dec 2022 at 08:18, Adam Gundry <<a href="mailto:adam@well-typed.com">adam@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 09/12/2022 07:38, Simon Peyton Jones wrote:<br>
> It seems to me that the only motivation for this proposal is for<br>
> Template Haskell generated code <br>
> <br>
> <br>
> I don't think so. Michael suggested another<br>
> <br>
> Another motivation: today it's generally considered Bad Practice to<br>
> use record syntax for the constructors of datatypes with<br>
> alternatives, because this generates partial field accessors. With<br>
> NoFieldSelectors, we can avoid this, but at the cost of turning off<br>
> field selector generation for the entire module, which we might not<br>
> want. Being able to control field selector generation on a<br>
> per-datatype level lets you use this trick while keeping other<br>
> "normal" records the same.<br>
> <br>
> I think this proposal is generally a good idea.<br>
<br>
I agree with Simon here: the motivation for this proposal is wider than <br>
just with TH. It will be useful to be able to explore designs where a <br>
single module includes one record datatype with selectors, and other <br>
datatypes that use the same field names but not selectors. Those might <br>
be TH-generated, but need not be in general.<br>
<br>
Moreover, I think it would be problematic to have features that are <br>
available only via TH splices and that cannot be translated to the <br>
underlying declarations. As a user I expect to be able to expand spliced <br>
declarations, and some users rely on this (e.g. to support <br>
cross-compilation scenarios where TH support is tricky).<br>
<br>
<br>
> If we have NoRecrodSelectors at all we should have it on a<br>
> per-data-type basis.<br>
<br>
Agreed. But what about per-field or per-constructor? The proposal allows <br>
these but I'm not convinced we need more than per-datatype, and that <br>
would reduce complexity.<br>
<br>
<br>
> I am exercised about the modifiers problem If we had modifiers we'd <br>
> definitely use them. Using pragmas temporarily adds friction because <br>
> we'll have to go through deprecation cycles to get rid of them.<br>
> <br>
> I think we should accept the proposal, but also proactively seek <br>
> implementation support for modifiers. If we push hard maybe we can get <br>
> modifiers in time not to have to go round the houses with pragmas.<br>
> <br>
> The only thing I'd like to add to the proposal is the specific modifier <br>
> design. What is the modifier name? From which module is the modifier <br>
> exported. That way when we get modifiers we don't have to start a new <br>
> debate.<br>
<br>
I think there is a debate to be had about whether modifiers are really <br>
the best approach in general. Is the lack of motivation to implement <br>
then a sign that we don't really need them?<br>
<br>
<br>
> On Thu, 8 Dec 2022 at 17:01, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a> <br>
> <mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>>> wrote:<br>
> <br>
> It seems to me that the only motivation for this proposal is for<br>
> Template Haskell generated code. So maybe we can imagine an<br>
> alternative that is purely in Template Haskell, without any syntax.<br>
> Which would avoid the concerns about parsing pragmas*. Maybe there<br>
> is room, in this space, for a generic mechanism, but I don't think<br>
> that we'd need this: it makes sense to let the Template Haskell<br>
> slice decide if a record it defines generates selectors or not.<br>
> <br>
> That being said, I'm personally ok with the proposal as it stands, I<br>
> think it makes sense. But it's likely that a pure Template Haskell<br>
> solution may be both more forward compatible and easier to implement<br>
> (at least, based on Vlad estimate, who knows this part of the code,<br>
> I'm inclined to believe so). As there doesn't seem to be any<br>
> particular motivation beyond Template Haskell, I'd be ok if we made<br>
> this counter-proposal.<br>
> <br>
> I don't think counterargument 4 is something we can oppose: it is<br>
> theoretically possible to define the doppelgänger record in a<br>
> separate module, but we know it won't happen. Matt Parsons mentions<br>
> the Esqueleto library, it is obvious that the library will prefer<br>
> using a silly name for record fields rather than ask its users to<br>
> move definitions to another module and the library will be right: it<br>
> is less obnoxious.<br>
> <br>
> All in all, I think that the proposal is quite reasonable, and would<br>
> open space in the design of Template-Haskell based libraries.<br>
> <br>
> * For the record, I don't think that we can claim that pragmas can<br>
> be ignored semantically. The OVERLAPPING pragma is a<br>
> counter-example. Maybe more acutely: the LANGUAGE pragma. So I don't<br>
> agree with counterargument 3.<br>
> <br>
> On Wed, 30 Nov 2022 at 22:18, Adam Gundry <<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a><br>
> <mailto:<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a>>> wrote:<br>
> <br>
> On 30/11/2022 20:37, Joachim Breitner wrote:<br>
> > Hi,<br>
> ><br>
> > Am Mittwoch, dem 30.11.2022 um 19:28 +0000 schrieb Adam Gundry:<br>
> >> What do you think?<br>
> ><br>
> > my initial feeling about `language … where …` is that it is a<br>
> modifer<br>
> > of sorts, however<br>
> > * with a syntax that may not scale well (hard to target<br>
> anything<br>
> > but a whole set of declarations)<br>
> > * looks like it could support any kind of language<br>
> extension, when<br>
> > it probably doesn’t make sense for all of them.<br>
> > so may not gain much over implementing (parts) of the<br>
> modifier syntax.<br>
> <br>
> Well, I find it hard to imagine really needing to enable an<br>
> extension<br>
> for anything smaller than a declaration group. On the other<br>
> hand, I not<br>
> infrequently want to enable particular extensions only for a few<br>
> specific definitions (AllowAmbiguousTypes comes to mind).<br>
> <br>
> As I understand it, modifiers need to be type-checked before<br>
> they have<br>
> meaning assigned. This presumably means they cannot change the<br>
> behaviour<br>
> of the parser, whereas an explicit "language ... where ..."<br>
> construct<br>
> could do so. And I don't think modifiers can scope over a<br>
> declaration<br>
> group, only a single declaration?<br>
> <br>
> I agree that we wouldn't necessarily support *all* language<br>
> extensions<br>
> locally, but I think the list for which this fundamentally does<br>
> not make<br>
> sense is relatively short (the main ones that come to mind are<br>
> import-related extensions such as ExplicitNamespaces). Others<br>
> might be<br>
> hard to specify/implement (e.g. Safe Haskell seems tricky) but<br>
> we could<br>
> simply not support them locally.<br>
> <br>
> <br>
> > ...<br>
> ><br>
> > Or we revive local modules, and use that as a then natural way of<br>
> > scoping language pragmas…<br>
> <br>
> There's clearly a relationship to local modules, but that seems<br>
> like<br>
> more complexity than we need for the problem at hand. I don't<br>
> see why we<br>
> shouldn't add "language ... where ..." now, then potentially later<br>
> support local (or top-level!) modules with<br>
> <br>
> language Blah where<br>
> module M where<br>
> ...<br>
> <br>
> After all, {-# LANGUAGE #-} pragmas violate the principle that<br>
> pragmas<br>
> shouldn't change semantics. ;-)<br>
> <br>
> Cheers,<br>
> <br>
> Adam<br>
> <br>
<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
27 Old Gloucester Street, London WC1N 3AX, England<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>