From: Satoshi Ogasawara <ogasawara@itpl.co.jp>
To: Philippe Veber <philippe.veber@gmail.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] a push style event combinator
Date: Fri, 16 Sep 2011 02:32:23 +0900 [thread overview]
Message-ID: <4E7236A7.7020902@itpl.co.jp> (raw)
In-Reply-To: <CAOOOohR4N++xB8wM23GpAaOuKV03mKnOs6-ty3suTyE+p-b1RA@mail.gmail.com>
(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 <ogasawara@itpl.co.jp <mailto:ogasawara@itpl.co.jp>>
>
> 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
>
>
prev parent reply other threads:[~2011-09-15 17:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-15 14:19 Satoshi Ogasawara
2011-09-15 14:45 ` Philippe Veber
2011-09-15 17:32 ` Satoshi Ogasawara [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=4E7236A7.7020902@itpl.co.jp \
--to=ogasawara@itpl.co.jp \
--cc=caml-list@inria.fr \
--cc=philippe.veber@gmail.com \
/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