[ghc-steering-committee] #512: NoFieldSelectors as datatype annotation, Recommendation: reject

[Vladislav Zavialov]

Dear Committee,

Matt Parsons has proposed #512 "NoFieldSelectors as datatype annotation".
Read it here:

https://github.com/parsonsmatt/ghc-proposals/blob/matt/field-selectors-scoped/proposals/0512-nofieldselectors-per-datatype.md

Background:
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).

Proposal Summary:
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.

The proposal introduces a new pragma-based annotation to declarations:
  data {-# NoFieldSelectors #-} R = MkR { fld :: Int }

The proposal also introduces constructor-level and field-level annotations:
  data R = {-# NoFieldSelectors #-} MkR { fld :: Int }
  data R = MkR { fld :: {-# NoFieldSelectors #-} Int }

Recommendation:
I recommend rejecting this proposal on multiple grounds.

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:
* special support in the parser (and the lexer)
* data structures to represent it in the AST, together with TTG extension
fields
* data structures in the Template Haskell AST and the corresponding
conversion logic between TH and GHC ASTs
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.

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.

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).

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).

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.

Let me know what you think. Discussion period: 2 weeks.

- Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20221130/0aa8bd91/attachment.html>