Skip to content
Snippets Groups Projects

Sort out treatment of underscores in types

    • Open Issue created by Richard Eisenberg @rae

    I can count 4 different meanings for underscores in Haskell programs:

    1. A pattern for which we don't care to write a name. (This dates back to antiquity.)

      Example:

      const x _ = x

    2. An expression for which we want GHC to tell us what its expected type should be. (Relatively new: these are typed holes.)

      Example:

      plus x y = x + _

    3. A type which we want GHC to infer, by looking at the expression. (Relatively new: these are wild cards in partial type signatures.)

      Example:

      plus :: forall a. Num a => a -> a -> _
plus x y = x + y

    4. A type which we want GHC to infer, by looking at the underscore's context. (Relatively new: these are wild cards in type applications.)

      Example:

      x = const @_ @Bool 'x'    -- the _ is inferred to mean Char

    Problems arise with the advent of visible kind application (#12045 (closed)): In type signatures, 3 of these meanings make sense (2, 3, and 4). In type/data family patterns, 3 of these meanings make sense (1, 2, and 4). Ideally, the user should have the opportunity to choose which meaning they want. In contrast, right now we use heuristics: in visible type/kind applications, we always use (4); otherwise, we use (1) (in patterns) or (3) (in types).

    This is a mess, for at least three reasons:

    A. Users might conceivably want different behavior than what we provide. For example, perhaps a user is writing an intricate pattern (at either term or type level) and wants to know the type (resp. kind) of the next bit of pattern. Or maybe the user wants to do this in a visible type application. Right now, there's just no way to do this.

    B. It causes trouble for pretty-printing. Aside from term-level patterns, all the uses of underscores above are stored identically in the AST. This means that they are printed identically. But that's strange. For example, uses (3) and (4) might have different underscores meaning different variables. Should we number the underscores? But that would be silly for usage (1). It's all a bit muddy.

    C. This causes awkwardness in the implementation. #12045 (closed) has to twiddle DynFlags to get its desired behavior, and that's sad.

    This ticket is to track resolutions to these problems.

    Trac metadata
    Trac field Value
    Version 8.7
    Type Bug
    TypeOfFailure OtherFailure
    Priority normal
    Resolution Unresolved
    Component Compiler
    Test case
    Differential revisions
    BlockedBy
    Related
    Blocking
    CC
    Operating system
    Architecture
    Edited by Simon Peyton Jones
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items ...

    • Activity

    Please register or sign in to reply