Re: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell

#7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by goldfire): This looks nice -- I can easily believe it works. Here is some feedback I have on the code: * I would want to see this handle `IrredPred` predicates, as well as tuples. That way, synonyms built with !ConstraintKinds would be fully supported by TH. I don't think this should be too much work beyond what you've already done. * I still think a change to !DsMeta is warranted. For example, I would imagine code like `[t| (Show a, (Read a, Num a)) => a -> a |]` would fail to compile, even though TH would now be able to represent such a predicate. * The functions `classP` and `equalP` in the `Lib` module are meant to echo the constructors of `Pred`. I would say that, now that `Pred` is a synonym, `classP` and `equalP` should be removed. (It took me a while to understand why all those functions are there in `Lib` -- the answer is that !DsMeta is ''much'' easier to write with those functions there.) Leaving `classP` and `equalP` doesn't cause anyone any real harm, but it would just be a small wart on the design that could easily be eliminated. * Along similar lines, you will probably find that you need an `equalityT` function in `Lib` when updating !DsMeta. * It looks like you left the old `Pred` commented-out in `Syntax`. * While it is probably too late now (and I don't think worth going back to fix), it's best to do whitespace changes in separate commits from substantive changes. Perhaps before editing a new file, removing the trailing whitespace, make a commit, and then go back and to the real changes. You can always then rebase at the end of your session to lump together all the whitespace commits. Continued thanks for working on this! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7021#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC