Hi Heinrich, Hi Ertugrul
thanks for all your comments so far. In last e-mail, you wrote:
Heinrich Apfelmus apfel...@quantentunnel.de wrote:
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
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
Heinrich Apfelmus apfel...@quantentunnel.de wrote:
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
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
Peter Althainz altha...@gmail.com wrote:
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
Ertugrul Söylemez wrote:
Heinrich Apfelmus apfel...@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
Heinrich Apfelmus apfel...@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
Ertugrul Söylemez wrote:
Heinrich Apfelmus apfel...@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
Heinrich Apfelmus apfel...@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
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
Heinrich Apfelmus apfel...@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
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,
Peter Althainz altha...@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
13 matches
Mail list logo
