[GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell
GHC
ghc-devs at haskell.org
Sat Jan 11 17:25:38 UTC 2014
#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
More information about the ghc-tickets
mailing list