[GHC] #9183: GHC shouldn't expand constraint synonyms

GHC ghc-devs at haskell.org
Tue Jun 10 16:54:42 UTC 2014


#9183: GHC shouldn't expand constraint synonyms
-------------------------------------+------------------------------------
        Reporter:  Feuerbach         |            Owner:
            Type:  feature request   |           Status:  new
        Priority:  normal            |        Milestone:
       Component:  Compiler          |          Version:  7.8.2
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------

Comment (by simonpj):

 I see what you want, but I don't see how to achieve it.

 Recall that
  * `:info f` takes a name `f` and tells you stuff about `f`
  * `:type e` takes an abritrary expression `e` and tells you its type

 If you use `:info showX` you'll see the type you expect.  If you use
 `:type showX` you are using `:type` with an "arbitrary expression" that
 turns out to be a single identifier.  So GHC instantiates it with fresh
 type variables, generates constraints, simplifies them, and then re-
 generalises. The instantiation, constraint simplification, and
 regeneration is what  expands the constraint synonym, and I don't see a
 robust way to stop that happening.

 We could make `:type` behave like `:info` when given a bare identifier.
 Or, in those same circumstances, we would make `:type` refrain from the
 "instantiate, simplify, generalise" hoopla.  But that would make `:type`
 on a bare identifier behave subtly differently to the way it does now.Is
 that special case worth it?  Or would it be better to encourage users to
 use `:info` whenever possible?

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


More information about the ghc-tickets mailing list