search

Gabriella439 / pipes

Compositional pipelines
BSD 3-Clause "New" or "Revised" License
487 stars 72 forks source link

Remove some redundant Monad constraints #144

Closed quchen closed 9 years ago

quchen commented 9 years ago

None of the following require a Monad constraint, yet they had one in their type signatures: yield, await, cat, request, respond, push, pull.

Gabriella439 commented 9 years ago

Actually, I did that intentionally. The reason why is that the semantic model for the Proxy type is:

data ProxyF a' a b' b x = Request a' (a -> x) | Respond b (b' -> x)

type Proxy a' a b' b = FreeT (ProxyF a' a b' b)

Under that semantic model those operations would have a Monad constraint (technically Functor, but I'm waiting for ghc-7.10 AMP to become more widespread). If you remove those constraints then it leaks details about the internal implementation.

quchen commented 9 years ago

I'd argue that the point of types is to be somewhat leaky: the absence of something means it cannot be used by the implementation. It took me a couple of clicks to find out that for is the actual reason the Monad constraint is in most of Pipes.Prelude, for example.

Gabriella439 commented 9 years ago

Right, but I want to reserve the right for the internal implementation to use the Monad constraint, even if it does not do so right now.

quchen commented 9 years ago

Hm, that's a valid point. I'll retract the request then.