[Haskell-cafe] Announcement - HGamer3D - 0.2.1 - why netwire

[Heinrich Apfelmus]

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