Peter Althainz | 22 Mar 20:13 2013
Picon

Announcement - HGamer3D - 0.2.1 - why netwire

Peter Althainz wrote:

> Dear All,
>
> I'm happy to announce release 0.2.1 of HGamer3D, the game engine with
> Haskell API, featuring FRP based API and FRP based GUI. The new FRP API
> is based on the netwire package. Currently only available on Windows:
> http://www.hgamer3d.org.

Nice work!

Of course, I have to ask: what influenced your choice of FRP library in
favor of  netwire  instead of  reactive-banana ?

Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

Hi Heinrich

good question, actually I need to thank you for your excellent tutorials
on FRP and GUI on the WEB. I tried the version of reactive-banana
without switches as the first FRP framework to have contact with and I
liked its simplicity and the cool introduction around Excel cells you gave on the Web.
HGamer3D is my personal way to get more insight into FP and Haskell
especially and from the beginning I wanted to have a FRP API to try it
with game examples. So your intro on FRP and the examples were very
helpful with that.
(Continue reading)

Ertugrul Söylemez | 22 Mar 21:58 2013
Picon

Re: Announcement - HGamer3D - 0.2.1 - why netwire

Peter Althainz <althainz <at> gmail.com> wrote:

> - What struck me was introduction of netwire author Ertugrul Söylemez
> on Arrows and the explanations of local state, which can be kept into
> an arrow. Since I was also curious on OOP and FP and game state
> handling, actually this raised some interest. So I think this "Arrows
> keep local state" argument was the killer feature. But also behaviours
> keep local state and maybe I got misguided here.

It's not arrows that keep local state, but it's specifically the
automaton arrows, in particular Auto and Wire.  Both are automaton
arrows.  One way to express Auto is the following:

    data Auto a b = forall s. Auto s ((a, s) -> (b, s))

Similarly Wire can be expressed like that (simplified):

    data Wire a b = forall s. Wire s ((a, s) -> (Maybe b, s))

Both contain a local state value and a transition function.  That's why
they are called automaton arrows.

> - I then did some trials with netwire and I felt it's a quite
> comprehensive and nice API, so I got started with that.

Thanks. =)

Greets,
Ertugrul

(Continue reading)

Heinrich Apfelmus | 23 Mar 10:35 2013
Picon

Re: Announcement - HGamer3D - 0.2.1 - why netwire

Peter Althainz wrote:
> Heinrich Apfelmus wrote:
>
>> Of course, I have to ask: what influenced your choice of FRP library in
>> favor of  netwire  instead of  reactive-banana ?
> 
> good question, actually I need to thank you for your excellent tutorials
> on FRP and GUI on the WEB. I tried the version of reactive-banana
> without switches as the first FRP framework to have contact with and I
> liked its simplicity and the cool introduction around Excel cells you 
> gave on the Web.

My pleasure. :) I have to thank Peter Minten for writing the tutorial 
with Excel cells, though.

> HGamer3D is my personal way to get more insight into FP and Haskell
> especially and from the beginning I wanted to have a FRP API to try it
> with game examples. So your intro on FRP and the examples were very
> helpful with that.
> 
> After reading a lot on the web it became clear, that currently
> reactive-banana and netwire are good candidates to start with. So why in
> the end I decided to use netwire for the binding?
> 
> It's some personal things and I do not claim to have done a proper
> evaluation or comparison. I also cannot judge on performance or other
> relevant topics. Having said that, I can give you some points why I 
> choosed netwire:
> - The cool simplicity of reactive-banana API seems to have suffered a
> little bit after the introduction of the switch functionality.
(Continue reading)

Ertugrul Söylemez | 23 Mar 17:02 2013
Picon

Re: Announcement - HGamer3D - 0.2.1 - why netwire

Heinrich Apfelmus <apfelmus <at> quantentunnel.de> wrote:

> You said that reactive-banana didn't feel as simple after the
> introduction of dynamic event switching, though. Could you pinpoint
> some particular thing that made you feel like that? Maybe a type
> signature or a tutorial or something else? I took great care trying to
> make the dynamic event switching stuff entirely optional, so you can
> use reactive-banana without understanding it at all, but I'm not sure
> if I succeeded.

I think this is less of an issue with reactive-banana than with classic
FRP in general.  The type signatures of Netwire can be scary at first
sight, but they are consistent throughout the entire library.  Once you
understand one of these type signatures you understand all of them.
Once you know how to use one wire, you know how to use all others.

Let me pinpoint something in particular: events.  In reactive-banana
events are special, in Netwire they are not.  This makes dynamic
switching special in reactive-banana and natural in Netwire.  Let me
show you an example:  You want to dispaly "one" for ten seconds, then
"two" for twelve seconds, then start over:

    myWire =
        "one" . for 10 -->
        "two" . for 12 -->
        myWire

Events and particularly dynamic event switching is one of the main
problems Netwire solves elegantly.  You can add this to reactive-banana,
too, but it would require changing almost the entire event interface.
(Continue reading)

Heinrich Apfelmus | 24 Mar 10:18 2013

Re: Announcement - HGamer3D - 0.2.1 - why netwire

Ertugrul Söylemez wrote:
> Heinrich Apfelmus <apfelmus <at> quantentunnel.de> wrote:
> 
>> You said that reactive-banana didn't feel as simple after the
>> introduction of dynamic event switching, though. Could you pinpoint
>> some particular thing that made you feel like that? Maybe a type
>> signature or a tutorial or something else? I took great care trying to
>> make the dynamic event switching stuff entirely optional, so you can
>> use reactive-banana without understanding it at all, but I'm not sure
>> if I succeeded.
> 
> I think this is less of an issue with reactive-banana than with classic
> FRP in general.  The type signatures of Netwire can be scary at first
> sight, but they are consistent throughout the entire library.  Once you
> understand one of these type signatures you understand all of them.
> Once you know how to use one wire, you know how to use all others.
> 
> Let me pinpoint something in particular: events.  In reactive-banana
> events are special, in Netwire they are not.  This makes dynamic
> switching special in reactive-banana and natural in Netwire.  Let me
> show you an example:  You want to dispaly "one" for ten seconds, then
> "two" for twelve seconds, then start over:
> 
>     myWire =
>         "one" . for 10 -->
>         "two" . for 12 -->
>         myWire
> 
> Events and particularly dynamic event switching is one of the main
> problems Netwire solves elegantly.  You can add this to reactive-banana,
(Continue reading)

Ertugrul Söylemez | 24 Mar 14:25 2013
Picon

Re: Announcement - HGamer3D - 0.2.1 - why netwire

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

(Continue reading)

Heinrich Apfelmus | 24 Mar 16:41 2013
Picon

Re: Announcement - HGamer3D - 0.2.1 - why netwire

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
(Continue reading)

Ertugrul Söylemez | 24 Mar 18:25 2013
Picon

Re: Announcement - HGamer3D - 0.2.1 - why netwire

Heinrich Apfelmus <apfelmus <at> quantentunnel.de> wrote:

> 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 you are thinking in primitive combinators.  Keep in mind that
context is nothing primitive.  In earlier releases of Netwire I had a
"manager" wire that allowed to manage a set of running wires by message
passing.  However, that wire turned out to be either too generic or too
specific.  There was no good balance, so I decided to get rid of it
altogether.

Now every library layer or application would write its own
application-specific manager wire.

> Again, I would be interested in an implementation of the BarTab
> example [2] to compare the two approaches.

I'm happy to provide one.  Please be patient until I release
netwire-vty, a terminal UI library based on Netwire.

Greets,
Ertugrul

--

-- 
(Continue reading)


Gmane