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

GHC ghc-devs at haskell.org
Mon Jan 13 21:47:17 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 yoeight):

 Replying to [comment:9 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.

 Do you have any pointer on what irreducible predicates are please ? If
 it's possible, could you provide a code sample that triggers irreducible
 predicate TH error ?

 >
 > * 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.
 You were right, I got an error when compiling your code. I think we should
 use it in a new test case in order to increase code coverage. What do you
 think ?
 >
 > * 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.
 >
 I agree. The thing is, I have `(add-to-list 'write-file-functions 'delete-
 trailing-whitespace)` in my `.emacs`. I didn't notice until I posted my
 patches.
 > Continued thanks for working on this!
 Thanks for your feedback !

 Yorick

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7021#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list