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

[Heinrich Apfelmus]

Ertugrul Söylemez wrote:
> Heinrich Apfelmus <apfelmus at quantentunnel.de> wrote:
> 
>> I concur that chaining wires with the andThen combinator is very
>> slick, I like it a lot. Wolfgang Jeltsch recently described a similar
>> pattern for classical FRP, namely a behavior that doesn't live
>> forever, but actually ends at some point in time, which can be
>> interpreted as an event occurrence. ("It ends with a bang!")
> 
> Well, that would work, but I wonder why then you wouldn't want to go all
> the way to signal inhibition.  You don't need AFRP to have it.  It's
> actually quite a light-weight change.  Allow behaviors not to produce a
> value, i.e. somewhere in your library replace "a" by "Maybe a".

I think that the  andThen  combinator is slick, but I'm not sure whether 
I find the underlying model -- signal inhibition -- to be equally 
pleasing. In the context of GUI programming, chaining several events 
with the  andThen  combinator is almost never needed, so I've postponed 
these questions for now.


>> How would you express the TwoCounters example [1] using dynamic event
>> switching in netwire? (The example can be implemented without dynamic
>> event switching, but that's not what I mean.) What about the BarTab
>> example [2]?
> 
> I've been asked that via private mail.  Let me just quote my answer:
> 
>     "This is a misconception caused by the very different nature of
>     Netwire.  In Netwire everything is dynamic.  What really happens in
>     w1 --> w2 is that at the beginning only w1 exists.  When it inhibits
>     it is removed from the network and w2 takes its place.  The missing
>     ingredient is that w2 is not actually produced by a wire, but this
>     is equally easy and natural.  Just consider the context wires:
> 
>         context id w
> 
>     This wire will dynamically create a version of 'w' for every
>     different input, so it acts like a router that will create wires if
>     they don't already exist.  Deletion works similarly:
> 
>         contextLatest id 1000 w
> 
>     This is a version that only keeps the 1000 latest contexts.

So  context  has the same purpose as Conal's  trim  combinator [1]. 
However, I believe that it is too inconvenient for managing very dynamic 
collections that need to keep track of state, as the  context  function 
significantly limits the scope of the stateful wire. That's why I've 
opted for a more flexible approach in  Reactive.Banana.Switch  , even if 
that introduces significant complexity in the type signatures. Again, I 
would be interested in an implementation of the BarTab example [2] to 
compare the two approaches.


   [1]: 
http://conal.net/blog/posts/trimming-inputs-in-functional-reactive-programming
   [2]: http://www.haskell.org/haskellwiki/Reactive-banana/Examples#bartab

Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com