Peter Althainz <[email protected]> wrote: > 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.
signature.asc
Description: PGP signature
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
