<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">
It seems to me that the only motivation for this proposal is for Template Haskell generated code
</div></blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I don't think so. Michael suggested another</div><div style="font-family:tahoma,sans-serif" class="gmail_default"></div><div style="font-family:tahoma,sans-serif" class="gmail_default">
<blockquote>
<p dir="auto">Another motivation: today it's generally considered Bad
Practice to use record syntax for the constructors of datatypes with
alternatives, because this generates partial field accessors. With
NoFieldSelectors, we can avoid this, but at the cost of turning off
field selector generation for the entire module, which we might not
want. Being able to control field selector generation on a per-datatype
level lets you use this trick while keeping other "normal" records the
same.</p>
</blockquote>
</div><div style="font-family:tahoma,sans-serif" class="gmail_default">I think this proposal is generally a good idea. If we have NoRecrodSelectors at all we should have it on a per-data-type basis.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I am exercised about the modifiers problem If we had modifiers we'd definitely use them. Using pragmas temporarily adds friction because we'll have to go through deprecation cycles to get rid of them.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I think we should accept the proposal, but also proactively seek implementation support for modifiers. If we push hard maybe we can get modifiers in time not to have to go round the houses with pragmas.<br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">The only thing I'd like to add to the proposal is the specific modifier design. What is the modifier name? From which module is the modifier exported. That way when we get modifiers we don't have to start a new debate.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 8 Dec 2022 at 17:01, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io">arnaud.spiwack@tweag.io</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"><div dir="ltr"><div>It seems to me that the only motivation for this proposal is for Template Haskell generated code. So maybe we can imagine an alternative that is purely in Template Haskell, without any syntax. Which would avoid the concerns about parsing pragmas*. Maybe there is room, in this space, for a generic mechanism, but I don't think that we'd need this: it makes sense to let the Template Haskell slice decide if a record it defines generates selectors or not.</div><div><br></div><div>That being said, I'm personally ok with the proposal as it stands, I think it makes sense. But it's likely that a pure Template Haskell solution may be both more forward compatible and easier to implement (at least, based on Vlad estimate, who knows this part of the code, I'm inclined to believe so). As there doesn't seem to be any particular motivation beyond Template Haskell, I'd be ok if we made this counter-proposal.</div><div><br></div><div>I don't think counterargument 4 is something we can oppose: it is theoretically possible to define the doppelgänger record in a separate module, but we know it won't happen. Matt Parsons mentions the Esqueleto library, it is obvious that the library will prefer using a silly name for record fields rather than ask its users to move definitions to another module and the library will be right: it is less obnoxious.</div><div><br></div><div>All in all, I think that the proposal is quite reasonable, and would open space in the design of Template-Haskell based libraries.<br></div><div><br></div><div>* For the record, I don't think that we can claim that pragmas can be ignored semantically. The OVERLAPPING pragma is a counter-example. Maybe more acutely: the LANGUAGE pragma. So I don't agree with counterargument 3.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 30 Nov 2022 at 22:18, Adam Gundry <<a href="mailto:adam@well-typed.com" target="_blank">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 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 modifer<br>
> of sorts, however<br>
> * with a syntax that may not scale well (hard to target anything<br>
> but a whole set of declarations)<br>
> * looks like it could support any kind of language extension, when<br>
> it probably doesn’t make sense for all of them.<br>
> so may not gain much over implementing (parts) of the modifier syntax.<br>
<br>
Well, I find it hard to imagine really needing to enable an extension <br>
for anything smaller than a declaration group. On the other 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 they have <br>
meaning assigned. This presumably means they cannot change the behaviour <br>
of the parser, whereas an explicit "language ... where ..." construct <br>
could do so. And I don't think modifiers can scope over a declaration <br>
group, only a single declaration?<br>
<br>
I agree that we wouldn't necessarily support *all* language extensions <br>
locally, but I think the list for which this fundamentally does not make <br>
sense is relatively short (the main ones that come to mind are <br>
import-related extensions such as ExplicitNamespaces). Others might be <br>
hard to specify/implement (e.g. Safe Haskell seems tricky) but 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 like <br>
more complexity than we need for the problem at hand. I don't 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 pragmas <br>
shouldn't change semantics. ;-)<br>
<br>
Cheers,<br>
<br>
Adam<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>
_______________________________________________<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>