#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 pggiarrusso):
Type synonyms are top level/global because all types and classes are. Otherwise type solving might be incoherent. -1 from me.
Type synonyms can be expanded, and using a synonym or its expansion should not affect coherence of type class resolution (what’s solving?).
Please explain why you couldn't declare the synonym at top level, as usual. Do you want the synonym to work wherever this module gets imported into? How will that go if it's nested?
Please provide a more focussed example. Line 202 of 707. Do you really need 707 lines to explain the need?
Looking at lines 189 to 207: the RHS of the type synonym refers to lexically scoped variables, so the poster has to lambda-lift the type synonym. That’s similarly annoying to any other use of lambda-lifting. Arguably, the poster is just asking for something with the semantics of let, but for types (ignoring the difference between let and where). I’d guess you’d want both, and you’ll probably get both in general in DependentHaskell. 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4020#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler