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

[Joachim Breitner]

Hi,

Am Mittwoch, dem 30.11.2022 um 14:08 +0300 schrieb Vladislav Zavialov:
> 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).

I wonder if there is another work-around: If the motivation is a module
full of TH-generated data types, and only some of them should get a
FieldSelector, couldn’t TH generate those fieldselectors that are
needed simply as plain functions? 

This makes me wonder: can the effect of NoFieldSelectors be really
undone using a plain function definition, or is there something about
field selectors that is special? Ah, probably the export/import  story…
I assume we don’t (yet?) have a way of bundling them with the type
constructor so that `import TyCon(..)` gets them as well?


I also wonder: Where do we want to steer Haskell here! While not a
strict rule, I believe we _do_ want to avoid, if possible, from
creating many different dialects in the long run, and (usually)
extensions should at least be plausible to become the default
eventually. Is that true for NoFieldSelectors? Do we envision that to
eventually become the default? If so, pragmas for turning it on
selectively don’t seem to be that useful.

(Until two days ago I would have been hesitant to imagine Haskell
without FieldSelectors on by default. Two days I go for the first time
worked on a code base with OverloadedRecordDot, and it felt
surprisingly smooth and elegant. Now I could imagine Haskell in the
long run weaning away from (automatic) field selector functions, and
reaching a future where one uses dot notation (and pattern matching, of
course) to get data out of records.)



About wanting to use modifier syntax instead: I sympathize with Matt’s
hesitancy.  Modifier syntax is not only unimplemented, it is also
untested, and (to me at least) it is unclear it will live up to the
generality it tries to apply to. (For example, we’ll see if using the
syntax of types is always the ergonomic syntax for annotation, if some
annotation really need bespoke syntax; if having types there, which at
least need to be name-resolutioned, may prevent their use in
annotations that affect name resolution; etc. – I digress) So if Matt’s
proposal was more compelling on other grounds, I may have suggested to
allow it in Pragma style.

But Vlad makes good arguments about the suggested changes not really
pulling their weight, and thus I concur with his recommendation.

Cheers,
Joachim



-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/