Peter Althainz wrote:
Hi Heinrich:
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.
In reactive banana we have considerably more types then in netwire:
- One tpye for Behaviours
- One type for Events
- sinks in addition: sinkoutput[text:==showNumber<$>result]- what is
that? (I know it has something to do with feedback loops)
- scary type for the network description: "forallt.Frameworkst=>Momentt()"
Thanks Peter!
The distinction between Behavior and Event is something fundamental that
I don't want to give up easily. They behave differently under products
and coproducts, they correspond to modalities in temporal logic and they
are also very useful for recursion.
Concerning the sink combinator, it's actually part of the GUI bindings
and not of the core library. It's used to bind, say the text value of an
edit widget to display the value of a Behavior String .
Likewise, the forall t. Frameworks t => Moment t () type signature is
used when binding to a GUI framework. The explicit forall is only used
to be get the right name for the type t , usually you would just write
Frameworks t => Moment t () .
Overall, I like to think that the complexity is only superficial. I
agree that the type parameter t is somewhat annoying, but it's necessary
for fundamental reasons. Fortunately, it has a nice conceptual
interpretation as "starting time".
In the case of HGamer3D, the sink combinator would replace the need
to declare a final "wire which runs all the wires at each step". It
feels a bit weird to me to have wires like guiSetPropW that perform
side effects, i.e. where it makes a different whether you observe their
results or not. That's a complexity where I feel that something "has
been swept under the rug".
Best regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
