Hello, I'm a bit confused on how to design graphical widgets to take advantage of FRP design. I'm trying to do things in threepenny-gui but I suppose the same question applies to any framework. Suppose I want to create a "file selection widget". Currently I have a function that takes a (FilePath -> UI()) function as a parameter: what to do when a file is selected; my function returns the "widget", so that the calling code can incorporate it in its UI. This works fine, but is not FRP, right? Should my function take no arguments and return a (Widget,Event FilePath) tuple, and let the calling code decide what to do with that event? Should it be a Behavior (the currently selected file of the widget)? I *think* I understand the principles of FRP, but I'm not getting what it means in terms of design. What are the advantages of returning an Event and letting the calling code do "on myEvent myWidget $ \file -> ..." instead of just passing the handler function as a parameter? I don't know if I make much sense. In any case, any pointer to non trivial FRP GUI code would be good! Thanks a million all, -- JP Moresmau http://jpmoresmau.blogspot.com/