caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Daniel Bünzli" <daniel.buenzli@erratique.ch>
To: Satoshi Ogasawara <ogasawara@itpl.co.jp>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] [ANN] PEC ver. 1.1
Date: Wed, 18 Apr 2012 15:27:21 +0200	[thread overview]
Message-ID: <2B372C89CE4F408688B67B090FA5105C@erratique.ch> (raw)
In-Reply-To: <4F8EA91C.3060001@itpl.co.jp>

Le mercredi, 18 avril 2012 à 13:44, Satoshi Ogasawara a écrit :
> But PEC dose not violate good semantics either. PEC treats only one event at any
> given time t. Please see blow code.


I don't think your code shows the problem I'm talking about.
  
> module E = Pec.Event.Make (Pec.EventQueue.DefaultQueueM) (Pec.EventQueue.DefaultQueueI)
> open Printf
>  
> let _ =
> let e, sender = E.make () in
> let e' = E.map (fun x -> sender 2; x + 1) e in (* during update cycle, send 2. *)


Here add :

let e'' = E.map (fun x -> sender 3; x + 1) e in  
  
and now what should the value of e be in the next update cycle ? All the options you have (keep only the first call to sender, keep only the last call to sender, keep both and execute one after the other) break the functional and compositional nature of FRP because it violates the semantics of events.

> To write event driven systems such like GUI sometimes needs a event-event chain
> without real-user actions. Sending events during update cycle is something unavoidable.


I don't have enough experience to assert that's really the case. However if that's needed I suspect that the way to resolve conflicts that break the semantics, should they arise, is actually very specific to the problem domain and shouldn't rely on anything related to the order of updates during the update cycle.  

The only thing I'm saying here is that your first message made it sound like PEC solved a problem of React ("You can send a value to event during update cycle."). It's not a problem of React it's a problem of interfacing FRP with your application domain. And React can perfectly be adapted to use the same unsound solution that PEC seems to use by adding the sender calls in a thunk queue and dequeing after the end of the update cycle.  
  
> Yes, weak-pointer-less implementation is one of my purpose. The key point is
> that dependency of events are represented by nested variants.


That doesn't really answer my question (or at least I don't understand what it means).

Best,

Daniel


  reply	other threads:[~2012-04-18 13:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-17 16:40 Satoshi Ogasawara
2012-04-17 17:52 ` Adrien
2012-04-17 18:50   ` Satoshi Ogasawara
2012-04-17 19:23 ` Daniel Bünzli
2012-04-18  1:59   ` Satoshi Ogasawara
2012-04-18  7:36     ` Daniel Bünzli
2012-04-18 11:44       ` Satoshi Ogasawara
2012-04-18 13:27         ` Daniel Bünzli [this message]
2012-04-18 17:39           ` Satoshi Ogasawara
2012-04-18 22:32             ` Daniel Bünzli
2012-04-19  8:59               ` Satoshi Ogasawara
2012-04-19 10:31                 ` Daniel Bünzli
2012-04-19 10:57                   ` Daniel Bünzli
2012-04-19 13:31                     ` Satoshi Ogasawara
2012-04-19 13:02                   ` Satoshi Ogasawara
2012-04-19 14:09                     ` Daniel Bünzli
2012-04-20  9:24                       ` Satoshi Ogasawara

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=2B372C89CE4F408688B67B090FA5105C@erratique.ch \
    --to=daniel.buenzli@erratique.ch \
    --cc=caml-list@inria.fr \
    --cc=ogasawara@itpl.co.jp \
    /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).