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@joachim-breitner.de http://www.joachim-breitner.de/