Skip to content
Snippets Groups Projects

The kind of (=>)

    • Closed Issue created by Andres Löh @kosmikus

    This is mainly a request for clarification, and not very important.

    Is there any good (theoretical, implementation, practical, ...) reason why (with ConstraintKinds) enabled, the => symbol on the type-level is still treated as a built-in syntactic construct rather than a type-level operator with

    GHCi> :kind (=>)
(=>) :: Constraint -> * -> *

    Note that I'm not actually proposing to make it re-definable, but to treat it similarly to the (->) type operator.

    Trac metadata
    Trac field Value
    Version 7.8.2
    Type FeatureRequest
    TypeOfFailure OtherFailure
    Priority low
    Resolution Unresolved
    Component Compiler
    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 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • Andres Löh changed weight to 3

      changed weight to 3

    • Andres Löh added Tfeature request Trac import labels

      added Tfeature request Trac import labels

    • Richard Eisenberg
      Richard Eisenberg @rae ·
      Developer

      Here's a reason: normally, if we know (a b c) ~ (d e f), it is reasonable to conclude a ~ d, b ~ e and c ~ f. But, what if a is really (=>)? Could b become (Eq a, Eq [a]) and e become Eq [a]? Is it the case that (Eq a, Eq [a]) ~ Eq [a]? These are logically equivalent, but are they equal in the sense of (~)? I would hope not. Indeed, even asking whether (a => b) ~ (c => d) right now is forbidden.

      There may be a reasonable way forward here, but it's not abundantly obvious. If you want More Thought put into this, do you have a use case in mind?

    • Andres Löh
      Andres Löh @kosmikus ·
      Author Reporter

      Thanks a lot for the answer. This is indeed the kind of problem I was suspecting behind the limitation, but I wasn't quite sure what issues there are.

      I don't need this in any way. I've just been explaining constraint kinds in the context of Haskell courses and talks a couple of times recently, and I always thought it would be nice to be able to get GHCi to output the kind of =>. But I completely understand that it may be problematic to make => completely first class.

      Feel free to close if you think this has no chance of being implemented any time soon.

    • Richard Eisenberg closed

      closed

    • Richard Eisenberg
      Richard Eisenberg @rae ·
      Developer

      I will close, but your post made me realize something. Instead of writing (Eq a, Show a, Read a) => a -> a, I can write Eq a => Show a => Read a => a -> a, which I somehow like more. Haven't checked how it Haddocks, though...

      Trac metadata
      Trac field Value
      Resolution Unresolved → ResolvedWon'tFix
    • Mateusz Kowalczyk
      Mateusz Kowalczyk @Fuuzetsu ·
      Reporter

      It Haddocks in whichever way you wrote it. Whether this is desirable or not is arguable but that's how it is.

    • Edward Kmett
      Edward Kmett @ekmett ·

      goldfire:

      Note: the latter is slightly weaker, since in Eq a => Show a => Read a => .. you can only reference backwards up the chain.

    • Ben Gamari added Plow label

      added Plow label

    Please register or sign in to reply