RE: [Template-haskell] two things I wanted from TH today
| > 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' because the kind of people who use TH also seem to be the kind of people who use GHC extensions! Re Ian's alternatives below, my own preference would be for (1) just because it's simple and direct. I think that TH users are savvy enough to absorb THSyntax changes without much pain, so backward compatibility isn't too big an issue. Esp since the HEAD contains lots of changes anyway. Simon | Hmm, we currently have | | data Body = GuardedB [(Exp,Exp)] | | NormalB Exp | | It looks like we would want either | | ----- 1 | data Body = GuardedB [(Guard,Exp)] | | NormalB Exp | | data Guard = NormalG Exp | | PatG [Stmt] | ----- | | or | | ----- 2 | data Body = GuardedB [(Exp,Exp)] | | PatGuardedB [(Guard,Exp)] | | NormalB Exp | | data Guard = NormalG Exp | | PatG [Stmt] | ----- | | or | | ----- 3 | data Body = GuardedB [(Exp,Exp)] | | PatGuardedB [([Stmt],Exp)] | | NormalB Exp | ----- | | 1 is the simplest overall, but I think it would set a bad precedent as | we wouldn't want future extensions to cause TH programs to break. | | 2 and 3 have the advantage that Haskell98+TH users can pretend nothing | happened. I think I prefer 2 over 3 as it's simpler to see what happens | when a GuardedB and PatGuardedB are concatenated. | | So I propose option 2. Does anyone disagree?
"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
participants (2)
-
Isaac Jones -
Simon Peyton-Jones