<div dir="ltr">OK  thank you very much, I hadn't seen that page!!<div><br></div><div>JP</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 8, 2014 at 10:04 PM, Heinrich Apfelmus <span dir="ltr"><<a href="mailto:apfelmus@quantentunnel.de" target="_blank">apfelmus@quantentunnel.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">JP Moresmau wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello, I'm a bit confused on how to design graphical widgets to take<br>
advantage of FRP design. I'm trying to do things in threepenny-gui but I<br>
suppose the same question applies to any framework.<br>
<br>
Suppose I want to create a "file selection widget". Currently I have a<br>
function that takes a (FilePath -> UI()) function as a parameter: what to<br>
do when a file is selected; my function returns the "widget", so that the<br>
calling code can incorporate it in its UI. This works fine, but is not FRP,<br>
right?<br>
<br>
Should my function take no arguments and return a (Widget,Event FilePath)<br>
tuple, and let the calling code decide what to do with that event? Should<br>
it be a Behavior (the currently selected file of the widget)? I *think* I<br>
understand the principles of FRP, but I'm not getting what it means in<br>
terms of design. What are the advantages of returning an Event and letting<br>
the calling code do "on myEvent myWidget $ \file -> ..." instead of just<br>
passing the handler function as a parameter?<br>
<br>
I don't know if I make much sense. In any case, any pointer to non trivial<br>
FRP GUI code would be good!<br>
</blockquote>
<br></div></div>
I have distilled some principles for FRP widget design and wrote them down here:<br>
<br>
<a href="https://github.com/HeinrichApfelmus/threepenny-gui/blob/master/doc/design-widgets.md" target="_blank">https://github.com/<u></u>HeinrichApfelmus/threepenny-<u></u>gui/blob/master/doc/design-<u></u>widgets.md</a><br>

<br>
They are not quite complete, though, in particular the section on implementation details is lacking, mainly because I'm not entirely sure on this myself.<br>
<br>
<br>
In your particular example, I would use an `Event FilePath` and make it part of the `Widget` type, so that you have a function<br>
<br>
   chosePath :: Widget -> Event FilePath<br>
<br>
The advantage of using first-class events, or FRP, in the first place is also briefly explained in the aforementioned document.<br>
<br>
>From a pragmatic point of view, you could say that you certainly don't lose anything by offering an Event instead of registering a callback function. :)<br>
<br>
<br>
Best regards,<br>
Heinrich Apfelmus<br>
<br>
--<br>
<a href="http://apfelmus.nfshost.com" target="_blank">http://apfelmus.nfshost.com</a><br>
<br>
______________________________<u></u>_________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>JP Moresmau<br><a href="http://jpmoresmau.blogspot.com/">http://jpmoresmau.blogspot.com/</a>
</div>