关于类型类中带占位参数方法的设计疑问及自定义类型类的实现考量

这是个非常好的问题，我来一步步拆解给你看：

为什么Data.Bits选择isSigned :: a -> Bool而非isSigned :: Bool？ #

主要有这几个核心原因：

• 历史兼容性与早期类型系统限制：在Haskell的早期版本（比如Haskell98）中，并不支持类型应用（比如isSigned @Int这种显式指定类型的写法）。如果把isSigned设计成无参的Bool，用户就没办法在没有显式类型注解的情况下调用它，而带一个占位参数的话，编译器可以通过参数的类型自动推断出要使用哪个实例的实现，这在当时是更实用的设计。
• 接口一致性：Data.Bits中的大多数方法（比如bit, shiftL, testBit）都是需要接收具体值来操作的。把isSigned也设计成接受同类型参数的形式，能让整个类型类的接口风格保持统一，用户使用时不用额外区分“哪些方法需要值、哪些不需要”，降低心智负担。
• 便捷的类型推断场景：在很多实际代码中，当你需要获取某个类型的isSigned属性时，往往已经持有该类型的一个值了。比如在一个处理Bits类型的通用函数里，你已经有x :: a变量，这时候写isSigned x比手动写类型注解（比如isSigned @a）要简洁得多，尤其在类型变量复杂或嵌套的场景下。

自定义类型类：是否要把method :: Bool改成method :: a -> Bool？ #

这取决于你的具体使用场景和目标环境：

• 如果需要兼容旧版Haskell（不支持类型应用），或者你的用户经常会在已有该类型值的上下文中调用这个方法，那改成带占位参数的形式会更友好，能提升代码的简洁性和易用性。
• 如果你的目标环境是支持现代Haskell特性（比如GHC 8.0及以上，支持类型应用），且这个方法确实只和类型相关，那保持无参形式也完全没问题，甚至更直观。另外，你还可以考虑用类型家族这种更现代的方式来实现，比如：

  class MyClass a where
    type Method a :: Bool
  

  这种方式可以直接通过Method Int这样的形式获取对应的值，完全不需要依赖值参数，是更纯粹的类型级解决方案。

备注：内容来源于stack exchange，提问作者G. Rodrigues