[GHC] #16082: Sort out treatment of underscores in types

GHC ghc-devs at haskell.org
Mon Jan 14 20:49:34 UTC 2019


#16082: Sort out treatment of underscores in types
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.7
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by adamgundry):

 * cc: adamgundry (added)


Comment:

 A few of us discussed this today, and came up with the following:
 * Treat anonymous wildcards `_` just like user-supplied metavariables, for
 the "I don't care" case. GHC should try to infer a value for the
 metavariable, and does not report anything (unless there is a genuine
 error, i.e. it is not possible to either solve or generalise over the
 metavariable). In particular, it becomes possible to write anonymous
 wildcards in more places, such as datatype and instance declarations.
 * Report named wildcards `_w`, including both type/kind and their
 instantiation (if one is determined by the context/expression), for the "I
 want help figuring out what this is" case.
 * We can optionally add flags to control this behaviour, e.g. to print out
 the inferred values for anonymous wildcards or suppress the named ones.
 * Add a separate syntactic cue indicating a partial type signature (e.g.
 use `:?` instead of `::`) for case 3. This avoids the oddity that
 introducing a wildcard means suddenly the expression no longer has a
 complete type signature.

 This probably needs a GHC proposal as the next step.

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


More information about the ghc-tickets mailing list