Peter Verswyvelen wrote:
Actually, I believe that many Yampa examples do separate the drawing
from the update... The arrow provides the game data that *can* be
rendered. If you provide interpolators for that game data, you can
still achieve the same as is explained in fix your timesteps (in my
On Sun, May 2, 2010 at 6:23 PM, Ben midfi...@gmail.com wrote:
hello --
i'm putting the finishing touches on a cabal package based on what
felipe gave, i've managed to make it an arrow transformer which is
nice. i have a few issues though.
1) i know it is not possible to add class
: Re: [Haskell-cafe] Re: FRP for game programming / artifical
life simulation
To: haskell-cafe@haskell.org
Message-ID: 20100429030922.ga7...@kira.casa
Content-Type: text/plain; charset=us-ascii
On Wed, Apr 28, 2010 at 04:16:08PM -0700, Ben wrote:
so i tried state machines of a sort
On Fri, Apr 30, 2010 at 3:37 AM, Daniel Fischer
daniel.is.fisc...@web.de wrote:
Am Donnerstag 29 April 2010 20:08:00 schrieb Ben:
A technical question: it seems like the instance of ArrowLoop is too
strict (this is something I've wondered about in Liu's paper too.)
Shouldn't it be
instance
Am Freitag 30 April 2010 17:23:19 schrieb Antoine Latter:
On Fri, Apr 30, 2010 at 3:37 AM, Daniel Fischer
daniel.is.fisc...@web.de wrote:
Am Donnerstag 29 April 2010 20:08:00 schrieb Ben:
A technical question: it seems like the instance of ArrowLoop is too
strict (this is something I've
FYI i got the lazy pattern match from Patterson's Programming with
Arrows, so I'm assuming it makes a difference. (I'll work out a real
example later.)
B
On Fri, Apr 30, 2010 at 8:45 AM, Daniel Fischer
daniel.is.fisc...@web.de wrote:
Am Freitag 30 April 2010 17:23:19 schrieb Antoine Latter:
Chris Eidhof wrote:
I agree. This would be an extremely useful feature, not only for game
development, but also for web development. We often use continuations
as a way to add state to the web, but this fails for two reasons:
whenever the server restarts, or when we scale to multiple machines.
On Wed, 28 Apr 2010, Ben wrote:
thanks for the comments, i'll try to respond to them all. but to
start off with, let me mention that my ultimate goal is to have a way
of writing down causal and robust (restartable) computations which
happen on infinite streams of data in a nice way -- by
Peter --
Thanks for the pointers. Have you seen
Uustalu T., Vene V. The Essence of Dataflow Programming
?
Can't say I understand it all but it is a compelling picture. I do
like the notion of distributive laws between monads and comonads.
B
On Wed, Apr 28, 2010 at 9:58 PM, Peter Gammie
), s1)
in (c, s2)
or do I misunderstand lazy pattern matching?
Best, B
Date: Thu, 29 Apr 2010 00:09:22 -0300
From: Felipe Lessa felipe.le...@gmail.com
Subject: Re: [Haskell-cafe] Re: FRP for game programming / artifical
lifesimulation
To: haskell-cafe@haskell.org
Lane --
Thanks for the suggestion, I'll take a closer look shortly. At the
moment I have to confess to not exactly understanding what your code
is doing, it's a little hairy for me? Right now I'm going to focus
on what Felipe has given me, it fits in nicely with the arrow
framework, which I'm
Am Donnerstag 29 April 2010 20:08:00 schrieb Ben:
A technical question: it seems like the instance of ArrowLoop is too
strict (this is something I've wondered about in Liu's paper too.)
Shouldn't it be
instance ArrowLoop SFAuto where
loop (SFAuto s f) = SFAuto s f'
where
Ah, thanks!
b
On Thu, Apr 29, 2010 at 11:37 AM, Daniel Fischer
daniel.is.fisc...@web.de wrote:
Am Donnerstag 29 April 2010 20:08:00 schrieb Ben:
A technical question: it seems like the instance of ArrowLoop is too
strict (this is something I've wondered about in Liu's paper too.)
Shouldn't
Basically, this is the differential equation hairball I mentioned earlier. You can
define a set of Operators -- a modification of Mealy automata that accepts two inputs -- and any
mapping of inputs to outputs within the Operation monad.
The Operation monad uses an existentially quantified
I want to save the state of the system to disk, I want to be able to
play the game, pick a point to stop, freeze it and turn off the
computer, and then come back later and resume. Why is that unwise?
What are the alternatives?
B
On Tue, Apr 27, 2010 at 9:28 PM, Christopher Lane Hinson
On Wed, 28 Apr 2010, Ben wrote:
I want to save the state of the system to disk, I want to be able to
play the game, pick a point to stop, freeze it and turn off the
computer, and then come back later and resume. Why is that unwise?
What are the alternatives?
B
On Tue, 27 Apr 2010, Ben
Interesting topic. I find it a bit annoying that Haskell doesn't
provide support to save functions. I understand this is problematic,
but it would be very nice if the Haskell runtime provided a way to
serialize (part of) the heap, making sure that pointers to compiled
functions get resolved
I agree. This would be an extremely useful feature, not only for game
development, but also for web development. We often use continuations as a way
to add state to the web, but this fails for two reasons: whenever the server
restarts, or when we scale to multiple machines.
However, I think it
On Apr 28, 2010, at 3:41 PM, Limestraël wrote:
I think the problem with function serialization is that unlike languages
which run over a virtual machine, bytecode generated by GHC is
platform-specific (just as compilated C or C++) and therefore can run
directly on top of the system, which
As a side note, it's interesting that C# doesn't allow serialization
of closures (anonymous delegates). The compiler-generated name
assigned to an anonymous delegate can be different after each
re-compilation. This is also really annoying in C#/.NET, since one
must explicitly add a named method if
I think y'all are talking past each other, a little bit. There are two ways to
serialize a function:
1) Serialize the bytecode for the function.
2) Serialize a persistant reference to a function that resides inside the
executable.
Personally, I think that either strategy is dubious. If you
thanks for the comments, i'll try to respond to them all. but to
start off with, let me mention that my ultimate goal is to have a way
of writing down causal and robust (restartable) computations which
happen on infinite streams of data in a nice way -- by which i mean
the declarative /
On Wed, Apr 28, 2010 at 04:16:08PM -0700, Ben wrote:
so i tried state machines of a sort
newtype STAuto s a b = STAuto { unSTAuto : (a, s) - (b, s) }
where the interruptibility would come from being able to save out the
state s. i was not successful, unfortunately, in this level of
Ben,
On 29/04/2010, at 6:16 AM, Ben wrote:
[...]
newtype STAuto s a b = STAuto { unSTAuto : (a, s) - (b, s) }
As Felipe observes in detail, this can be made to work. He uses Read and Show
for serialisation, but clearly you can use whatever you like instead.
I just wanted to add that one
slightly off topic, but how does one handle pausing / saving /
restarting in the FRP framework, especially the arrowized version?
i've only been able to do this via explicit (or monadic)
state-passing, e.g. imperative / piecemeal versus declarative /
wholemeal, which seems against the spirit of
I'm not sure exactly what you want to do. It should certainly be easy to
freeze an FRP program by lying about the amount of time that is passing and
witholding all events. Do you want to save an FRP system instance to disk (generally
unwise), or something else (what?).
Friendly,
--Lane
On
2010/4/25 Patai Gergely patai_gerg...@fastmail.fm:
(in my own FRP experiments I have an update thread and a render thread).
I wonder how to nicely deal with state that requires communication with
the outer world, even though it is functional at heart. For instance, if
you want to change a
Luke Palmer wrote:
The workhorse of our game has so far been generalized differentials.
While not entirely rigorous, they have provided a very nice framework
in which to express our thoughts and designs, and are very good at
highly dynamic situations which appear in games. For example,
1) In FRP, there is no global *type* GameState that stores the whole
game state. Rather, the game state is implicit in the collection of
active computations. This is also why state updating and drawing is
woven together in FRP, which is good syntactically, but hard to
disentangle for
Actually, I believe that many Yampa examples do separate the drawing
from the update... The arrow provides the game data that *can* be
rendered. If you provide interpolators for that game data, you can
still achieve the same as is explained in fix your timesteps (in my
own FRP experiments I have
(in my own FRP experiments I have an update thread and a render thread).
I wonder how to nicely deal with state that requires communication with
the outer world, even though it is functional at heart. For instance, if
you want to change a vertex buffer or a texture or whatever during the
update,
31 matches
Mail list logo