English version
Accueil     Ŕ propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis ŕ jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml ŕ l'adresse ocaml.org.

Browse thread
React.E.switch issue.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-09-28 (11:57)
From: Daniel_BĂĽnzli <daniel.buenzli@e...>
Subject: Re: React.E.switch issue.
Sorry I'm travelling in a sparsely connected area. Besides I'm heading
to a region where it seems the internet was closed down by the local
government. If that is still the case I won't be able to respond for
some weeks.

Now quickly two things.

1) It seems to me that you are using events where signals should be
used. Signals should be used to represent "state". Your "accumulating
event" sounds like state to me, use a signal for that.

2) If you really want a primitive event (or signal) to generate new
_primitive_ event occurences (or signal updates), just wrap the call
to the event sending (or signal update) function in a thunk and store
it in a queue, once the update cycle is over dequeue the next thunk
and invoke it. Fixed point operators will in effect perform something
similar but preserve the applicative nature of your program -- however
I think that you are right in your case they won't help.

Now I really suggest you to think hard about 1). I'm sure you can get
a clean solution, something like use S.fold with the (primitive) event
of the server to accumulate the unparsed input and remember the last
parsed message.