Browse thread
Recursion on React.events.
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Guillaume Yziquel <guillaume.yziquel@c...> |
| Subject: | Re: Recursion on React.events. |
Daniel Bünzli a écrit :
>> 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.
>
> Here :
>
> http://erratique.ch/software/react/doc/React.E.html#VALswitch
>
> Second bullet.
I think you should really make a direct link to this page from either
http://erratique.ch/software/react/doc/React.html
or
http://erratique.ch/software/react/doc/index.html
because I've been on your website quite a few times, and it's the first
time I see this page. (Which is really useful).
>> 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
>
> Yes it's confusing. It's here to allow to define mutually recursive
> definitions and still expose them to the outside world. It is also
> usefull if you have other values that depend on the delayed value and
> you want to expose them to the outside world. There are example of
> this in the breakout.ml example.
>
> [snip] I tried to rexeplain E.fix and S.fix but I came up with what's
> written in their documentation sorry.
>
> Daniel
Same comment for E.fix as for E.switch. I have never seen its
documentation before. It's much much clearer now.
All the best,
--
Guillaume Yziquel
http://yziquel.homelinux.org/