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

Ertugrul Söylemez es at ertes.de
Sun Mar 24 14:25:57 CET 2013


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".


> However, do note that the andThen combinator in netwire can only be so
> slick because "switching restarts time" (as the documentation puts
> it). I don't see a nice way to switch between wires that have
> accumulated state.

Time doesn't necessarily restart.  This choice is left to the (-->)
combinator.  I've decided for that one to restart time, because it
more closely resembles the behavior of other libraries.  As a
counterexample consider this:

    time . holdFor 0.5 (periodically 1) <|> 2*time

This wire will switch back and forth between the two wires 'time' and
'2*time' filling the gap between the inactive times of each.  Unlike
(-->), the (<|>) combinator keeps state.  This is also true for the
context wires (see below).


> 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.  There
    is also the classic dynamic switcher called 'switch':

        switch nw w

    This wire acts like 'w' until 'nw' produces a new wire, then
    switches to that one.  Indeed 'nw' is of type Wire e m a (Wire e m a
    b).

    Really nothing is static in Netwire.  It's actually very easy to
    write combinators like 'switch' and 'context' yourself.  In fact you
    can even write a sensible ArrowApply instance.  The problem is that
    it would have linear time complexity with respect to the number of
    instants that have passed, so it's not exactly useful."

Notice that wires (just like all other arrowic automata in Haskell)
switch all the time.  Moving forward in time involves switching, so it's
their very nature to do it.  They could decide to switch to anything
(provided the types fit) and they can observe the switching of other
wires.  There is no need for special library support for wires that
manage a set of wires.


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130324/7ca47ab7/attachment.pgp>


More information about the Haskell-Cafe mailing list