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

Joachim Breitner mail at joachim-breitner.de
Wed Nov 30 20:37:24 UTC 2022


Hi,

Am Mittwoch, dem 30.11.2022 um 19:28 +0000 schrieb Adam Gundry:
> What do you think?

my initial feeling about `language … where …` is that it is a modifer
of sorts, however
 * with a syntax that may not scale well (hard to target anything
   but a whole set of declarations)
 * looks like it could support any kind of language extension, when
   it probably doesn’t make sense for all of them.
so may not gain much over implementing (parts) of the modifier syntax.

But thinking outside the box:

Isn’t there already a warning flag that GHC implicitly turns off when
working on TH-generated files? So could we use the same machinery and
allow, _without actual surface syntax_, and only via the TH API, toggle
some flags that then should apply or not apply when type-checking the
TH output?

   enableExt :: Extension -> Q ()
   disableExt :: Extension -> Q ()
   
But yes, this also has it’s problems. Soon people will ask for this
ability to scope over just _some_ of the generated declarations. And,
maybe worse, if TH can produce something that doesn’t exist as source,
then it’ll cause headaches for those who need to write splices to file for
cross-compilation…

And the syntax-representable version of this idea is … precisely your
langauges … where … idea :-)

Or we revive local modules, and use that as a then natural way of
scoping language pragmas…

Cheers,
Joachim



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



More information about the ghc-steering-committee mailing list