English version
Accueil propos Tlchargement Ressources Contactez-nous

Ce site est rarement mis jour. Pour les informations les plus rcentes, rendez-vous sur le nouveau site OCaml l'adresse ocaml.org.

Browse thread
Recursion on React.events.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-12-09 (18:24)
From: Guillaume Yziquel <guillaume.yziquel@c...>
Subject: Re: Recursion on React.events.
Daniel Bünzli a écrit :
>> Daniel Bünzli's module is great, but sometimes a bit rough
>> to get by, specifically on examples such as this one.
> I would just like to point out that this has nothing to do with the
> module per se but understanding frp in general and this is the reason
> why I went to great length to document the semantics for each of the
> combinators I provide --- something most frp libraries won't bother to
> do, leaving you with testing or looking into the implementation for
> understanding things when tricky simulateneity issues arise.

I appreciate the documentation effort you put up. Really.

> Thus to understand why your event didn't work you could have done the
> following. Provided you understand the notations given here :
> http://erratique.ch/software/react/doc/React#sem

I do. I've done quite a lot of maths after all, and this doesn't 
frighten me.

> Since we have [schedule st]_st = Some (), by the semantics of E.map we
> have [ee]_st = Some ev. Thus we are in the second case of the semantics
> of E.switch (see doc) and the semantics of the switch reduces to the
> semantics of ev, i.e.

Maybe I was looking in the wrong place, but I haven't found "the second 
case of the semantics of E.switch" on your website. In fact, the way I 
learned about React.E.switch was from the .mli-style webpage on your 
website, and by trial and error.

> Pure equational reasoning, it's not that hard, or is it ?

Less than semi-algebraic geometry.

More seriously, the point was not understanding why it failed. I came to 
the same conclusions from empirical evidence. The point was how to 
overcome it.

And while I do not doubt that your documentation is rather explicit, I 
was nevertheless confused by your fixed point operators, and thus rather 
reluctant to use them.

The example on your website:

> let history ?(eq = ( = )) s = 
>   let push v = function 
>     | [] -> [ v ] 
>     | v' :: _ as l when eq v v' -> l
>     | l -> v :: l  
>   in
>   let define h = 
>     let h' = S.l2 push s h in 
>     h', h'
>   in
>   S.fix [] define

One thing that really troubles me, is that I do not understand why 
define returns a couple of two identical element. And the typing of 
E.fix is rather confusing:

> val fix : ('a React.event -> 'a React.event * 'b) -> 'b

Why do we return a 'b type with E.fix?

While the webpage mentions this dependence on the value at t-dt, it's 
quite hard to infer from the use of the fix point operator in the 
example how it's really supposed to behave and to be called.

Clarifying these issues would be welcome.

All the best,

      Guillaume Yziquel