#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