David Virebayre wrote:

Heinrich Apfelmus wrote:

...

Do you know any *small GUI programs* that you would *like* to see *implemented with Functional Reactive Programming?*

I may have an example.

I want to hear!

...

I would love to hear your examples, so that I can try to convert them to FRP style and test my library against them!

You want a description of the example, or the complete source code to make it work ?

Just a description. :) You can also mention why you find it interesting etc. That said, I'm mainly interested in the GUI, so if the example includes elaborate functionality unrelated to GUIs/audio/animation, linking to the source code would be nice (in imperative style or whatever you have, I will do the conversion to FRP). Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

On 11:09 Fri 08 Jul , David Virebayre wrote:

2011/7/8 Heinrich Apfelmus :

...

I want to hear! Just a description. :) You can also mention why you find it interesting etc.

Well I have an old program sitting around. Anyway, it's very simple :

The GUI has - a window with a menu bar, 2 directory selects (source and dest directories), 1 file select ( the 'patch file'), 1 textview to write logging information, and a 'Convert' button to start. - an about window that opens from a 'About...' menuitem - A status bar.

The convert button stats an action that scans all applicable files in a source directory, converts them and writes them in a destination directory.

The conversion itself is irrelevant to the topic, in my case it consists in searching for patterns in the file and replacing them, according to a list of changes read from a file, the 'patch file'.

The progression is logged in the textview: file processed, strings replaced. In the status bar, a percentage bar grows.

This provides another interest. wxHaskell has file dialogs, which are not events, but instead raw IO actions. -- Mats Rauhala MasseR

On Fri, Jul 8, 2011 at 12:51 AM, Heinrich Apfelmus wrote:

Jason Dagit wrote:

...

Heinrich Apfelmus wrote:

...

Do you know any *small GUI programs* that you would *like* to see *implemented with Functional Reactive Programming?*

I would love to hear your examples, so that I can try to convert them to FRP style and test my library against them!

How about a GUI for darcs?

This would involve a lot of functionality unrelated to GUIs. Could you break it down to a minimal "GUI-only" example that still gets the point across?

Just in case you don't already know this, you can use darcs as a library (take a look at the darcs cabal file). Jason

Dmitriy Nikitinskiy wrote:

Heinrich Apfelmus пишет:

...

Do you know any *small GUI programs* that you would *like* to see *implemented with Functional Reactive Programming?*

Maybe realize on FRP one of following bored examples:

CRUD table: create, update, delete records in table (for example Person records), with validating user input, auto-calculated fields (current age by birth date), totals by column, filtering. I think same GUI tasks get solved many GUI developers in imperative style. I hope solution of such day-tasks in FRP will be elegant

That's a great example! Keeping track of databases is very common (emails, reference manager, iTunes, ...), I'll definitely try to implement an example like this.

Simple GUI designer (uml-diagrams or reports): very intresting to see FRP approach (events on custom drawing elements, inplace modification of elements)

I take it that a vector drawing application like InkScape demonstrates the same concepts? Or this there anything specific to GUI designers? Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

Ketil Malde wrote:

Heinrich Apfelmus writes:

...

Do you know any *small GUI programs* that you would *like* to see *implemented with Functional Reactive Programming?*

I don't know if this fits the bill, but a tool that I'd like to see is plotting for one or more live streams of data. I guess I want something similar to timeplot, but listening on an input stream and updating/scrolling the plot. Think 'tail -f /var/log/messages | awk something | liveplot options'.

This has been requested a lot, I like it. If you could provide me with a tiny Haskell program that fetches a suitable data source (Yahoo stock prices, MacOS X system data, anything) and parses it; this would make my job even easier. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

Chris Smith wrote:

Heinrich Apfelmus wrote:

...

Do you know any *small GUI programs* that you would *like* to see *implemented with Functional Reactive Programming?*

This isn't really a specific application, but what I'd like to see most from FRP is an example of something that involves moving between windows and dialog boxes. All of the GUI-based FRP examples I've seen so far involve interactions in a specific GUI layout. It's unclear to me how FRP extends into a situation like:

- There's a starting window showing several options for what to do - When the user chooses an option, that window closes, and a new one opens with that activity. - In response to some actions, dialog boxes appear with their own interactions.

It's not clear to me if anyone in FRP has an idea of how stuff like this fits in. Is there some FRP trick to handle this declaratively? Or would you just say each move to a new window ends or pauses one network of events and behaviors, and starts a new one?

That's a very good example. Unfortunately, I am one of those who don't have any idea of how stuff like this fits in. :) I think it's possible to get something like this with pausing and resuming event networks, but a general and elegant formulation would probably rely on dynamic event switching, which I haven't attempted to implement yet. I'm trying to pick the low hanging fruit first. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

KC wrote:

Can one do FRP with Haskell connected to Javascript in the browser? I believe there is a standalone version of Javascript.

Well, there is http://www.flapjax-lang.org/ for Javascript FRP. I don't think it makes much sense to control real-time client-side interaction by server-side Haskell, the latency is just too big. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

On Sat, 9 Jul 2011, Heinrich Apfelmus wrote:

...

Oh, I am addressed explicitly, thanks! Yes, GUI for 'streamed' would be nice, too. In the meantime I switched from an approach with lazy lists to one with arrow-like stream processors. This way I could resolve all issues with wrong timing and inappropriate waiting, but now code looks more low-level. There are some examples lying around, that I even not started to implement, because I expect that implementing them in the current low-level way will yield nasty bugs. Thus I am highly interested in more sophisticated MIDI stream editor combinators. I expect that inspiration from other FRP frameworks would help me.

Of course, my intention was that you throw away your stream processors and use reactive-banana for everything. ;D I have made sure that it can be used both for real-time and for offline computations.

Could you expand a little on your arrow-like stream processors? What do the arrows look like,

data SF a b = SF (a -> (b, SF a b))

?

My stream processors are not Arrows, because 'first' cannot be implemented. However, 'arr' and '.' can be implemented. As far as I understand, the SF banana can only produce an output if an input event arrives. But my stream processor can set alarms in order to produce a clock signal. This way they can generate output without any input. Currently my stream processors are defined using an explicit state, that is hidden using an existential quantifier, but of course I would prefer a Haskell 98 solution. For example, an arpeggiator stream processor consists of two functions: 1. Receive key up/down events and keep track of the currently pressed keys. 2. Receive a MIDI controller that controls the tempo of the arpeggiator. The stream processor sets the alarm according the current tempo and at every alarm event it sends a single key chosen from the set of the currently pressed keys. This example shows, that a stream processor cannot support Arrow.first, that is extending (arrow a b) to (arrow (a,c) (b,c)), since for an alarm event, we have no input of type c that could be passed through. Currently I have build the two tasks into one stream processor. I would like to split these into two processors. This looks difficult to me, since the first stream processor (for management of pressed keys) must provide a state (the set of pressed keys) whenever the second stream processor (for clock generation) needs it.

Which additional primitives did you include, for instance

switch :: SF in (out, Maybe t) -> (t -> SF in out) -> SF in out delay :: Time -> SF a b -> SF a b

?

Since I have no Arrow instance I even have to write my own combinators that are counterparts to (&&&) and friends.

And of course, I am particularly interested in the nasty examples that you came up with. :)

For example I want to write a Guitar simulator: You press a set of keys together and the processor converts this into successive tones on a guitar. Technically I like to do it this way: When a key is pressed, collect all key press events in the following 10ms. After this period emit all pressed keys according to a certain pattern. When one of the pressed keys is released, then send key-press(!) events for all currently pressed keys according to another pattern. Repeat this cycle. Manage somehow the keys that are pressed after the first key-down-collecting phase and the keys that are released during this initial phase. Ignore them or do something more sensible about them, but make sure that in the output all key-down events are eventually matched with a key-up event and that for the same key you never send two successive key-down events or two successive key-up events. That is, for the same key, key-up and key-down events must alternate. An exception might be if you receive bogus input. But even then, the number of key-up and key-down events for one note in the output shall match, whenever this is true for the input. For lazy lists you can do time related processing by splitting the list of events and process the prefix differently from the suffix and then concatenate the results. This is easy and declarative, but you have no guarantee that the resulting stream processing is causal and that the timing is correct. (The second problem arises when merging two event lists. Merging implies that when waiting for two events then actually the system waits for the later of the events, but we need to wait for the first of the two events.)

Henning Thielemann wrote:

Heinrich Apfelmus wrote:

...

Could you expand a little on your arrow-like stream processors? What do the arrows look like,

data SF a b = SF (a -> (b, SF a b))

?

My stream processors are not Arrows, because 'first' cannot be implemented. However, 'arr' and '.' can be implemented.

[..]

For example, an arpeggiator stream processor consists of two functions: 1. Receive key up/down events and keep track of the currently pressed keys. 2. Receive a MIDI controller that controls the tempo of the arpeggiator. The stream processor sets the alarm according the current tempo and at every alarm event it sends a single key chosen from the set of the currently pressed keys.

This example shows, that a stream processor cannot support Arrow.first, that is extending (arrow a b) to (arrow (a,c) (b,c)), since for an alarm event, we have no input of type c that could be passed through.

Ok, that sounds nasty.

...

And of course, I am particularly interested in the nasty examples that you came up with. :)

For example I want to write a Guitar simulator: You press a set of keys together and the processor converts this into successive tones on a guitar.

Technically I like to do it this way: When a key is pressed, collect all key press events in the following 10ms. After this period emit all pressed keys according to a certain pattern. When one of the pressed keys is released, then send key-press(!) events for all currently pressed keys according to another pattern. Repeat this cycle. Manage somehow the keys that are pressed after the first key-down-collecting phase and the keys that are released during this initial phase. Ignore them or do something more sensible about them, but make sure that in the output all key-down events are eventually matched with a key-up event and that for the same key you never send two successive key-down events or two successive key-up events. That is, for the same key, key-up and key-down events must alternate. An exception might be if you receive bogus input. But even then, the number of key-up and key-down events for one note in the output shall match, whenever this is true for the input.

The guitar simulator is a great example! And much to my surprise, it's already possible to implement (parts of) it in reactive-banana 0.4.1! At least in the real-time version, where we have access to timers from wxHaskell. In particular, have a look at the new Wave.hs example, to be found at the bottom of http://haskell.org/haskellwiki/Reactive-banana/Examples It generates a wave-like pattern whenever you click on of the buttons (strum a chord). When you click two buttons in rapid succession (think left = key-down, right = key-up), the second wave will not start after the first one has completed. (I think this example also makes it clear that it's already to possible to implement the arpeggiator as you described with timers.) Of course, the code is not particularly high-level; after all, I am essentially duplicating event streams as [(Duration,a)]. Then again, we cannot describe each wave as Event a because we need a notion of "this event stream has finished" in order to be able to stall the second wave. In other words, the vanilla Event a is potentially infinite, there is no way to test whether it has "finished", so *some* other notion is needed anyway. Question: how would you actually like to describe the guitar simulator at a high-level? Did you already wish for some specific combinators? Assume that you had something like reactive-banana available and imagine that there were a benevolent djinn granting you three new primitive combinators of your choice. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

Henning Thielemann wrote:

Heinrich Apfelmus wrote:

...

Question: how would you actually like to describe the guitar simulator at a high-level? Did you already wish for some specific combinators? Assume that you had something like reactive-banana available and imagine that there were a benevolent djinn granting you three new primitive combinators of your choice.

If I would know of appropriate combinators, I would just implement them and not ask the djinn. :-)

Fair enough. :D How did you do it with lazy lists? The more I think about it, the more I come to the conclusion that it's impossible to implement this without duplicating the event data type. As said, the main problem is that you want a combinator append :: Pattern -> Pattern -> Pattern that plays the second pattern (event sequence, the guitar strum) right after the first one. This means that patterns are *finite*, but this seems to collide with the requirement that any FRP style Event must be potentially infinite. Once you do implement a small DSL for patterns, everything is fine, though, as the Wave.hs example demonstrates. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

On Sat, Jul 9, 2011 at 7:58 AM, Henning Thielemann wrote:

My stream processors are not Arrows, because 'first' cannot be implemented. However, 'arr' and '.' can be implemented. ... Since I have no Arrow instance I even have to write my own combinators that are counterparts to (&&&) and friends.

If you have arr, (.) and (&&&), then you have first as well: f **** g = (arr fst >>> f) &&& (arr snd >>> g) first' f = f **** arr id Am I missing something here? =) Cheers, -- Felipe.

1. Paul Hudak is writing a new book. http://plucky.cs.yale.edu/cs431/reading.htm

Wow... this is going to be my bedside reading. I haven't read the original Haskell School of Expression, did it use FRP back then? 2011/7/11 Paul Liu

You guys might want to checkout the recent work on Euterpea at Yale CS. In particular:

1. Paul Hudak is writing a new book. http://plucky.cs.yale.edu/cs431/reading.htm 2. It uses FRP and arrows for sound synthesis. 3. It combines FRP signals with monadic (which recently gets re-written in arrows) GUI composition. 4. New novel techniques is being developed to handle I/O within arrows framework.

The code can be obtained through darcs, details at http://plucky.cs.yale.edu/cs431/software_resources.htm

Notably, the way it handles GUI is that the composition of widgets are static, but the signals flowing between them are dynamic. This closely follows Conal Elliott's Phooey approach, and greatly reduces the complexity of GUI programming.

Disclaimer: I was an ex-student who worked on this project.

Regards, Paul Liu

On Thu, Jul 7, 2011 at 11:08 PM, Heinrich Apfelmus wrote:

...

Dear Haskellers,

Can GUI programming be liberated from the IO monad?

-- Regards, Paul Liu

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Paul Liu wrote:

You guys might want to checkout the recent work on Euterpea at Yale CS. In particular:

1. Paul Hudak is writing a new book. http://plucky.cs.yale.edu/cs431/reading.htm 2. It uses FRP and arrows for sound synthesis. 3. It combines FRP signals with monadic (which recently gets re-written in arrows) GUI composition. 4. New novel techniques is being developed to handle I/O within arrows framework.

The code can be obtained through darcs, details at http://plucky.cs.yale.edu/cs431/software_resources.htm

Thanks! Paul Hudak has kindly drawn my attention to Euterpea as well.

Notably, the way it handles GUI is that the composition of widgets are static, but the signals flowing between them are dynamic. This closely follows Conal Elliott's Phooey approach, and greatly reduces the complexity of GUI programming.

From what I understand, this new approach to I/O for arrows is equal in expressiveness to the approach I took in reactive-banana . Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com