caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Daniel Bünzli" <daniel.buenzli@erratique.ch>
To: guillaume.yziquel@citycable.ch
Cc: caml-list@inria.fr
Subject: Re: React.E.switch issue.
Date: Mon, 28 Sep 2009 16:57:41 +0500	[thread overview]
Message-ID: <91a3da520909280457r57eae06dpeb109acac8a7c0da@mail.gmail.com> (raw)
In-Reply-To: <4ABB7ECA.7080105@citycable.ch>

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.

Best,

Daniel


      reply	other threads:[~2009-09-28 11:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-24  7:40 Guillaume Yziquel
2009-09-24  8:01 ` Guillaume Yziquel
2009-09-24 13:42 ` Daniel Bünzli
2009-09-24 14:14   ` Guillaume Yziquel
2009-09-28 11:57     ` Daniel Bünzli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=91a3da520909280457r57eae06dpeb109acac8a7c0da@mail.gmail.com \
    --to=daniel.buenzli@erratique.ch \
    --cc=caml-list@inria.fr \
    --cc=guillaume.yziquel@citycable.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).