Skip to content
Snippets Groups Projects

Type classes in Backpack signatures are dodgy

    • Closed Issue created by Edward Z. Yang @ezyang

    At the moment, we allow exactly the same type class declarations in hsig files as we do in hs-boot files, and matching requires the type class definitions to match up exactly. But this is quite questionable.

    First, this means that I can't write this in a signature:

    class K a where
  f :: a -> Bool

    but then implement K with a type class that provides a default. The matching code will say these are not compatible. That's not so useful.

    Second, it means that I can WRITE a default implementation in a signature file. That seems like a step too far: there are many things I might like to write in a specification of a type class, but what the default methods are seems like a step too far.

    So it seems we need to fix two things:

    1. Relax matching so that you can add defaults post-facto in the implementation of the type class
    2. Make hsig more restrictive w.r.t. what class definitions it will accept.
    Trac metadata
    Trac field Value
    Version 8.1
    Type Bug
    TypeOfFailure OtherFailure
    Priority normal
    Resolution Unresolved
    Component Compiler (Type checker)
    Test case
    Differential revisions
    BlockedBy
    Related
    Blocking
    CC
    Operating system
    Architecture
    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