[GHC] #10098: Refactor wild card renaming

[GHC]

#10098: Refactor wild card renaming
-------------------------------------+-------------------------------------
              Reporter:              |             Owner:  thomasw
  thoughtpolice                      |            Status:  new
                  Type:  bug         |         Milestone:  7.12.1
              Priority:  normal      |           Version:  7.11
             Component:  Compiler    |  Operating System:  Unknown/Multiple
              Keywords:              |   Type of failure:  None/Unknown
          Architecture:              |        Blocked By:
  Unknown/Multiple                   |   Related Tickets:  #9922
             Test Case:              |
              Blocking:              |
Differential Revisions:  Phab:D613   |
-------------------------------------+-------------------------------------
 Imported from #9922, comment #5:

 ---------------------

 Austin: let's merge this to 7.10.1.

 Thomas: I'm not very happy with the way that wild-card error reporting is
 done.
 I think we discussed this before, but left it on one side until it was all
 working.  Which it now is.  What I suggest is this:

 Things I dislike:

  * I dislike the `checkParitalTypeSignature` and `checkNoPartialType`
 stuff in `RdrHsSyn`.  The only checks that belong in `RdrHsSym` are ones
 that prevent you building a syntax tree at all.  All other checks are best
 done later, when good error reporting is easier, and you can recover from
 errors.

  * I particularly hate the `RnTypes.extractWildcards` stuff.  It's like a
 whole extra renaming pass over the type, changing `HsWildCardTy` to
 `HsNamedWildCardTy` with an `Exact` `RdrName` in it.  Yuk!

 Here is a possible plan:

  * Remove all the checking from `RdrHsSyn`, unless we can't build a syntax
 tree without it.

  * Collapse `HsWildcardTy` and `HsNamedWildcardTy` into one, with a
 boolean (or a `Named`/`Anonymous` flag) to distinguish.

  * Provide a specialised version of `rnLHsType`, perhpas
 `rnLHsTypeWithWildCards`, that does the inital pass to find the named
 wildcards and bring them into scope.  This version is called in the places
 where you can have a type with wildcards, namely
    * `TypeSig`
    * `ExprWithTySig`
    * `rnHsBndrSig`

  * `rnLHsTypeWithWildCards` can work like this:
    1. Collect all the named wildcards, and bring them into scope.  This is
 a simple, ''pure'' function.
    2. Call `rnLHsType`.  When `rnLHsType` finds an anonymous wildcard,
 just make up a fresh name, rather than looking it up.
    3. Collect all the wildcards (named or anonymous) to get a `[Name]`;
 again a pure function
    4. Return the renamed type and the wildcard names
    That makes three passes, but each is simple.  In fact (1) and (4) could
 perhaps be the same function, with a boolean flag to say which wildcards
 to return.

  * All this means that when `rnLHsType` is called directly (not via
 `rnLHsTypeWithWildCards`) on a type like `_ -> Int`, it will succeed,
 generateing a fresh name for the `_`.  That's fine.  In `tc_hs_type` we
 will find it is not in scope, so we can say "Unexpected wildcard in type",
 and the enclosing location information will nail down the details.

  * There are, I think, three places where `HsWithBndrs` is used:
 `HsDecls.HsTyPats`, `HsDecls.RuleBndr`, `HsPat.SigPatIn`.  In the latter
 two I think that wildcards should be legal; in the first not so.  (Do you
 have tests for all three?)  So the caller of `rnHsBndrSig` should check
 for empty wildcards in the cases where there shouldn't be any.  I this
 this is just in type/data family patterns.

 I have not throught throught the extra-constraints wild card, but I think
 a similar plan should work.

 Does this make sense?  Might you do it?  (To HEAD, of course.)

 Thanks

 Simon

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