"Simon Peyton-Jones"
| > But it doesn't look like Pattern Guards are available in THSyntax yet.
The question is whether we want THSyntax to absorb all GHC extensions. I guess the answer does seem to be 'yes, on demand' (snip)
Let's say we have a library that exports TH functions, and a user of that library. I imagine that the user of TH-generated code can use -fth (but not -fglasgow-exts) and be safe if the code compiles without complaining: they're not using any extensions. But nothing prevents the author of the library from "accidentally" employing glasgow-exts in TH-generated code... It would be nice if the compiler could somehow prevent me from doing so. Some ideas offhand: - Have another module, THSyntaxGlasgowExts. - Have two packages provide THSyntax, one has extensions and one doesn't. That way, the user can employ a command-line flag to allow or disallow extensions, just as they do for hand-generated Haskell code. In any case, I'd tend to agree that it's fine to add extensions to THSyntax for now, since TH users probably use extensions, and once TH settles down more (and maybe gets adopted by other implementations some day), you can always implement a non-extension API...
because the kind of people who use TH also seem to be the kind of people who use GHC extensions!
I can imagine that the reasons that some people avoid extensions are that 1) they want to remain compatible across compilers, 2) they are concerned for the longevity of code that employs unstable language features, and 3) they don't understand or don't want to understand the extensions. Of course, the same reasoning applies to using TH since it is itself an extension :) peace, isaac