From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p8FHWaxl027777 for ; Thu, 15 Sep 2011 19:32:37 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAE02ck7Y5v4vmWdsb2JhbABCmGKOdRQBAQEBAQYNCwcUJoFTAQEEAScRNgoBBQsLGAkDARACCAcJAwIBAgEzAREGDQYCAQEOh2UEtjiGdASHbYtahRyMHQ X-IronPort-AV: E=Sophos;i="4.68,388,1312149600"; d="scan'208";a="120011978" Received: from amout07.alpha-mail.net ([216.230.254.47]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Sep 2011 19:32:30 +0200 Received: from webarc04.alpha-mail.jp (webarc04 [216.230.254.84]) by amout07.alpha-mail.net with ESMTP id p8FHWQeo017357; Fri, 16 Sep 2011 02:32:26 +0900 X-Virus-Scanned: amavisd-new at Alpha-Mail Out Received: from ltsub01.alpha-mail.net (ltsub01 [216.230.254.29]) by webarc04.alpha-mail.jp (Postfix) with ESMTP id 827E91C080D2; Fri, 16 Sep 2011 02:32:25 +0900 (JST) Received: from [192.168.1.3] (FL1-27-127-63-135.aic.mesh.ad.jp [27.127.63.135]) by ltsub01.alpha-mail.net (Alpha-mail) with ESMTP id 150EE3B8098; Fri, 16 Sep 2011 02:32:24 +0900 (JST) Message-ID: <4E7236A7.7020902@itpl.co.jp> Date: Fri, 16 Sep 2011 02:32:23 +0900 From: Satoshi Ogasawara User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Philippe Veber Cc: caml-list@inria.fr References: <4E72096C.1040904@itpl.co.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] a push style event combinator (2011/09/15 23:45), Philippe Veber wrote: > Thank you for releasing your library, it looks really interesting ! Thank you for your reply. > How would you compare it with react (http://erratique.ch/software/react) which, AFAIU, can > be used for similar purposes ? At least I can see there is no notion of signal (continuous > function of time) in PEC (or maybe signals can be emulated somehow ?). Also could you > comment on the 'no memory leaks' feature ? Yes, both the react and PEC can be used for similar purpose. But there are some different points between the two libraries. - PEC is "subscribe" centered. If you leave a event alone without subscribing, no actions will be occurred even if you send data to the event. The react library's system always runs update cycle at sending data to events. - Instead of signal, PEC have "value" function. "value" function attaches a event and returns a reference cell which contains latest occurrence data of the event. I think it's enough because signal is only terminal point of reactive events. - PEC's inside representation of event is not dependency graph but just nested variants. Let me assume a event A depends on other event B. In case of using dependency graph, event B has pointer of event A. This caused difficulty about memory leaks because there is no good timing to free the event A. PEC's event is just a nested variants. It means that event A has pointer of event B. So the event A will be garbage-collected automatically when the reference to the event A from application layer disappeared. That is the reason why "no memory leaks". Regards, ogasawara > > cheers, > Philippe. > > > 2011/9/15 Satoshi Ogasawara > > > Hello, > > I'd like to announce the release of PEC, a push style event combinator. > > PEC : https://github.com/osiire/Pec > > This small module(about 350 LOC) provides > > - a composable event. > - map, choose, never, join and several useful functions. > - immediate reactions corresponds sending data to events. > - no memory leaks. > > I think PEC is useful to write event driven systems. The signature is as follows. > > type 'a event > > (** [make ()] makes a new event and sender function.*) > val make : unit -> 'a event * ('a -> unit) > val map : ('a -> 'b) -> 'a event -> 'b event > > (** [choose l] is a event which will be raised when one of specified events occurred. *) > val choose : 'a event list -> 'a event > val never : 'a event > (** [join ee] is a event which will be raised when a inner event occurred. > "Inner event" is a event comes from outer event [ee]. *) > val join : 'a event event -> 'a event > (** [bind e f] is [join (map f e)] *) > val bind : 'a event -> ('a -> 'b event) -> 'b event > val scan : ('a -> 'b -> 'a) -> 'a -> 'b event -> 'a event > val filter : ('a -> bool) -> 'a event -> 'a event > val filter_map : ('a -> 'b option) -> 'a event -> 'b event > val zip : 'a event -> 'b event -> ('a * 'b) event > val take_while : ('a -> bool) -> 'a event -> 'a event > val take_while_in : ('a -> bool) -> 'a event -> 'a event > val take_n : int -> 'a event -> 'a event > val once : 'a event -> 'a event > val drop_while : ('a -> bool) -> 'a event -> 'a event > val drop_n : int -> 'a event -> 'a event > val delay : int -> 'a event -> 'a event > val pairwise : 'a event -> ('a * 'a) event > > (** [subscribe f e] attaches the [f] to the specified event. > The [f] will be called when the [e] will occurred. *) > val subscribe : ('a -> unit) -> 'a event -> unit > > (** [value e] returns a reference cell which store a latest value *) > val value : 'a -> 'a event -> 'a ref > > (** [run ()] runs PEC event system and returns a number of queuing size of sended data. *) > val run : unit -> int > > > e.g. > Using PEC, you can write a drag event from mouse events like this. > > let (+>) f g = g f > (* E is PEC module *) > let dragging mouse_down mouse_up mouse_move = > E.bind mouse_down (fun dloc -> E.choose [ > E.map (fun uloc -> `Drop (dloc, uloc)) mouse_up; > E.map (fun mloc -> `Drag (dloc, mloc)) mouse_move; > ] > +> E.take_while_in (function `Drop _ -> false | _ -> true)) > > > Regards, > ogasawara > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > >