Peter Althainz
Its simply the types are more cumbersome, now. In netwire you basically have one type, which is "Wire ...." with some type parameters (underlying monad, inhibition type, in-type, out-type), When underlying monad and inhibition type is choosen, you can define a type synonym and all boils done to "GameWire a b" in all types, events (GameWire a a), behaviours (GameWire a b), what you want. Signal inhibition makes Events and Behviours looks equal. Also the overall network has this type. And by the way, no generalized datatypes (forall t. ....), which I'm also not too comfortable with.
Actually for the higher rank types there is a rationale: safety. In fact I first had this: type Event e m = forall a. Wire e m a a However, this turned out to be too restrictive, when I decided to simplify it: type Event e m a = Wire e m a a The reason is that many events like 'require', even though they still act like identities, have to examine the input value to make decisions. Also you can expect that there will be at least one higher rank type in all libraries I release based on Netwire, for example my upcoming Vty-based text UI library: simpleUI :: (Monad m) => (forall a. m a -> IO a) -> UI m () b -> IO b The first argument is a monad morphism. It would be totally fine for it to be less restrictive for this case, but I want to stick with categorical concepts as far as possible. This makes it easier to reason about the code. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad.