[GHC] #4020: Please consider adding support for local type synonyms

[GHC]

#4020: Please consider adding support for local type synonyms
-------------------------------------+-------------------------------------
        Reporter:  nr                |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  low               |            Milestone:
       Component:  Compiler (Type    |              Version:  6.12.2
  checker)                           |
      Resolution:                    |             Keywords:  type synonym
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by AntC):

 Replying to [comment:17 pggiarrusso]:
 > A local type synonym should arguably be expanded, and only be in scope
 in its where clause, or in general in the lexical scope of the
 declaration. Probably the synonym should be expanded when exiting the
 synonym’s scope, so that error messages for type errors in the block use
 the synonym and not its expansion.

 GHC constantly strives to provide error messages that pinpoint a problem
 as closely as possible. Consider

 {{{
 x :: String
 x = "hello"
 y :: [Char]
 y = "world"

 xy = x + y    -- error: no instance for (Num String)
 yx = y + x    -- error: no instance for (Num [Char])
 }}}

 So the error message uses the declared type/synonym where it can. (I
 imagine that's rather fragile.) It doesn't look for a synonym that would
 be equivalent to some type.

 Why not: declare the synonym at top level, as usual; omit it from the
 module's export list so its scope is only the module; if you want a let-
 bound var declared with the synonym you can, and error messages will use
 that.

 Yes, lambda-lift for lexically scoped type vars. I'm not seeing that's a
 big burden. But if it is, perhaps it'll spur someone to put in a properly
 explained proposal on github.

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