[GHC] #14119: Refactor type patterns

[GHC]

#14119: Refactor type patterns
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                Owner:  (none)
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.1
      Resolution:                    |             Keywords:  TypeInType
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:  12564, 14038
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 I was thinking only of a counterpart to `Type`, not `HsType`. Your comment
 about type-level as-patterns is a good observation.

 It may be worth considering the situation in terms: Currently both
 patterns and expressions are parsed as expressions. (I believe there is
 some scenario where the parser can't be sure what it's looking at until
 it's too late. Maybe top-level TH splices. Maybe something more
 fundamental. The details aren't important here.) Then, another pass
 converts the expressions to patterns, erroring if the parsed expression
 doesn't form a pattern. Then, expressions and patterns are renamed and
 typechecked in different algorithms (mutually recursive ones, of course).

 Why have `HsPat` distinct from `HsExpr`? One reason I can think of is that
 `HsPat` is renamed very differently than `HsExpr` is: the former brings
 variables into scope, while the latter uses variables already in scope.

 The situation is a bit different in types. In particular, variable usages
 in type patterns do ''not'' bring those variables into scope. Instead, GHC
 looks through a type pattern before renaming it, gathers its free
 variables, and brings them into scope. This is subtly different than just
 having the variable occurrences bring them into scope, but it allows non-
 linear patterns, for example.

 I don't yet see a compelling reason for `HsTyPat`. If you want as-
 patterns, then we add a new constructor to `HsType`. As-patterns are
 rejected from the normal type kind-checker but accepted in the type
 pattern kind-checker.

 On the other hand, maybe it would indeed be better to have `HsTyPat`
 distinct from `HsType`.... usually, more types are better, no? :)

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