<div dir="ltr">Dear Committee,<br><br>Matt Parsons has proposed #512 "NoFieldSelectors as datatype annotation". Read it here:<br><br><a href="https://github.com/parsonsmatt/ghc-proposals/blob/matt/field-selectors-scoped/proposals/0512-nofieldselectors-per-datatype.md">https://github.com/parsonsmatt/ghc-proposals/blob/matt/field-selectors-scoped/proposals/0512-nofieldselectors-per-datatype.md</a><br><br><div>Background:</div><div>An older (accepted and implemented) GHC Proposal #160 "NoFieldSelectors" introduced a language extension flag to control whether top-level field selectors for record data types are generated. That is, when the programmer writes data R = MkR { fld :: Int }, shall we generate a top-level fld :: R -> Int or not? The answer in #160 is to make this controlled by the "FieldSelectors" language extension (enabled by default).</div><div><br></div><div>Proposal Summary:</div><div>In the new GHC Proposal #512, Matt argues that the control provided by the language extension introduced in #160 is insufficiently fine-grained, since it applies per-module, not per-definition. Matt has a use case where declarations are generated by Template Haskell and he would like to disable generation of field selectors for the generated declarations.</div><div><br></div><div>The proposal introduces a new pragma-based annotation to declarations:</div><div>  data {-# NoFieldSelectors #-} R = MkR { fld :: Int }<br></div><div><br></div><div>The proposal also introduces constructor-level and field-level annotations:</div><div><div>  data R = {-# NoFieldSelectors #-} MkR { fld :: Int }</div></div><div><div>  data R = MkR { fld :: {-# NoFieldSelectors #-} Int }</div></div><div><br></div><div>Recommendation:</div><div>I recommend rejecting this proposal on multiple grounds.</div><div><br></div><div>1. The first reason is the implementation (and maintenance) cost. GHC lacks generic infrastructure for pragmas, so every additional pragma means that we add at least the following:</div><div>* special support in the parser (and the lexer)</div><div>* data structures to represent it in the AST, together with TTG extension fields</div><div>* data structures in the Template Haskell AST and the corresponding conversion logic between TH and GHC ASTs</div><div>Maybe more, this is off the top of my head. And the proposal introduces not one but three places where a new pragma is allowed. This complexity needs to be justified.<br></div><div><br></div><div>2. The second reason is the existence of a more compelling alternative. I mentioned the lack of generic infrastructure for pragmas, but we do have an accepted proposal for generic annotations: it's #370 "Syntax for Modifiers". If the proposal switched to syntax introduced in #370, it would address the first objection. However, the author is unwilling to do so as long as #370 is not implemented (even though it's an accepted proposal). The author argues that we could switch to the modifiers syntax in the future, but it does not actually address my concern: if we get the pragma syntax, it's going to stay with us forever (that is how things typically work in GHC), and supporting *both* the pragma and modifiers would be worse still.</div><div><br></div><div>3. The third reason is ideological. Pragmas are syntactically similar to comments because (ideally) one should be able to ignore them. We use them to define rewrite rules, to mark fields unpacked, or to add cost centre annotations, because it only affects the performance/profiling, not the semantics of the code. But here, a pragma would affect what names are brought into scope, and as such, it shouldn't really be a pragma (syntactically).</div><div><br></div><div>4. The fourth reason is that an easy workaround is available. Just move declarations into a separate module with "NoFieldSelectors". I understand that it might be unsatisfactory and inconvenient, but it works and I'm weighing it against the maintenance cost mentioned in (1).</div><div><br></div><div>To summarize, I'm not thrilled about adding a feature that (1) imposes maintenance costs on GHC, (2) could be done better, (3) uses inappropriate syntax, and (4) has a readily available workaround. I recognize the author's motivation but I believe their use case can be addressed in a more principled way using #370 Modifiers.</div><div><br></div><div>Let me know what you think. Discussion period: 2 weeks.</div><div><br></div><div>- Vlad</div></div>