[Haskell-cafe] Observer pattern in haskell FRP

[Ertugrul Söylemez]

Nathan Hüsken <nathan.huesken at posteo.de> wrote:

> > Actually it is very scalable, as the same map is passed to every
> > object. It can even live in the underlying monad, which means that
> > you could even use a mutable vector, if you wish; however, I don't
> > recommend that.
> >
> > Remember that a map is immutable and shared, so passing the same map
> > to multiple objects is in fact the same as passing a pointer in
> > C++. Lookups in and updates to the map are of logarithmic
> > complexity, so this scales well.  Only doubling the number of nodes
> > actually adds one full step to lookups and updates.
> >
> > If you're dealing with millions of objects you may want to use the
> > vector solution mentioned earlier.  This requires an imperative
> > underlying monad, but you would get about the same speed as in C++.
>
> I might just not be used enough to functional data structures, "Purely
> functional data structures" is on my reading list :).
>
> I was thinking, in the asteroids example the only reason why the view
> needs more input than the models output, is that it needs to be
> informed of creation and destruction of asteroids.

Why would the view need to be informed?


> So, in the model one could habe a signal
>
> asteroidsModel :: Signal Input [Just AsteroidModel]
>
> which outputs "Nothing" for asteroids that have been destroyed.
> Then, in the view this would be taken for as input for
>
> asteroidsView :: Signal [Just AsteroidModel] [Picture]
>
> asteroidsView would have to do the following:
> * route the input list to a list of "asteroidView" signals.
> * When there is a "Nothing" in the input list, the corresponding (now
> exploding) view is moved to a list of "zombie asteroids" where it
> remains until its explosion animation is over.
> * When the input list is longer than the list of current astroidView
> signals, the list is extended.
>
> This would avoid the need for bookkeeping ids.

This is a very complicated way to do it.  I would simply regard the
"zombie asteroids" as regular objects.  That way you don't need a
special case in the view.


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/20121212/57f037d7/attachment.pgp>