Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#9115 closed feature request (wontfix)

The kind of (=>)

Reported by: kosmikus Owned by:
Priority: low Milestone:
Component: Compiler Version: 7.8.2
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


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.

Change History (5)

comment:1 Changed 3 years ago by goldfire

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?

comment:2 Changed 3 years ago by kosmikus

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.

comment:3 Changed 3 years ago by goldfire

Resolution: wontfix
Status: newclosed

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...

comment:4 Changed 3 years ago by Fuuzetsu

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

comment:5 Changed 3 years ago by ekmett


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

Note: See TracTickets for help on using tickets.