From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=5.0 tests=DNS_FROM_RFC_POST,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 410B6BC37 for ; Mon, 28 Sep 2009 13:57:42 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoEAKdBwErRVdvfkGdsb2JhbACRZohePwEBAQEJCQwHEwOrCI4FAQMCBYImgXMFgj2GTg X-IronPort-AV: E=Sophos;i="4.44,466,1249250400"; d="scan'208";a="33690405" Received: from mail-ew0-f223.google.com ([209.85.219.223]) by mail2-smtp-roc.national.inria.fr with ESMTP; 28 Sep 2009 13:57:41 +0200 Received: by ewy23 with SMTP id 23so4213497ewy.26 for ; Mon, 28 Sep 2009 04:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=wp2XNGAntqLmd5t32Di0hCe8t4gU4Ok5pJ5m6uh1T4E=; b=qCaEB0hmEPM1K86Q3PF4lXsgbYgPX4L5KrXrDGvZc+UorfHj74oUYArOPRfBrLrm3x ZnDTjerV0hUHlYCHFdyjDSm763NgwMPkD/VPxns9L1CirHceY8hmtcp0H1WYrS7GNhwN 3LchuEmoFM374TcCt7YjV6qB1PlSl9Se/XjME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ga6bcA75mFPNEBTncKByaCcsvFVFaeYs1piCLVNv4gHg2f/4+3MHyQhuQ3EXMlK9Tw pCXPr0mfOs9mRXQrqYbC/T3VodgSG/PcKkmmcGDVNIYGFrJMmFFBY0+r5hVdmR9HJibg NjbjQrAayN/GiFz7lZL4JSp5jGvGjVESvBrq8= MIME-Version: 1.0 Sender: daniel.c.buenzli@gmail.com Received: by 10.211.153.14 with SMTP id f14mr3603579ebo.36.1254139061279; Mon, 28 Sep 2009 04:57:41 -0700 (PDT) In-Reply-To: <4ABB7ECA.7080105@citycable.ch> References: <4ABB2264.1090409@citycable.ch> <91a3da520909240642p1df60421k209e7ae16e9403ef@mail.gmail.com> <4ABB7ECA.7080105@citycable.ch> Date: Mon, 28 Sep 2009 16:57:41 +0500 X-Google-Sender-Auth: 6099655b101fd488 Message-ID: <91a3da520909280457r57eae06dpeb109acac8a7c0da@mail.gmail.com> Subject: Re: React.E.switch issue. From: =?UTF-8?Q?Daniel_B=C3=BCnzli?= To: guillaume.yziquel@citycable.ch Cc: caml-list@inria.fr Content-Type: text/plain; charset=UTF-8 X-Spam: no; 0.00; buenzli:01 occurences:01 applicative:01 invoke:01 parsed:01 primitive:02 primitive:02 seems:03 seems:03 preserve:03 daniel:04 daniel:04 fold:06 queue:07 function:08 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