Basic FRP

Hey! this looks pretty fun.   I'm also looking forward to Ingo Maier's work in scala.react, as I see a lot of good coming from this style of programming.

Are you also using scala's continuations under the hood?

On Thu, May 27, 2010 at 7:59 PM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:

Hello everyone.I started working on a very basic implementation of an FRP library.Ingo Maier's scala.react is almost finished, and my library is not really in competition with something that sophisticated. It's simpler and more verbose than his. The basic idea is to have an API similar to the collections API, with map, flatMap, foreach, etc.Here is some simple example usage (there's more, see sources):

import reactive._ object Main extends Application with Observing {
// Signals
val num = Var(10)  // create a mutable Signal[Int] val string = num map {_.toString}   // create a signal equivalent to applying toString on num// could also have written for(n <- num) yield n.toString
val clock = new Clock_(interval = 1000)  // the _ is due to a bug in eclipse on windows disallowing a file called CLOCK$. Fixed in newer eclipse milestones.
val string2 = for(s <- string; c <- clock) yield s + " " + clock.toString

// Events
string.change foreach println // change is an EventStream of the signal's type firing whenever it's updated // really ".change" could be left out due to an implicit
val es = new EventStream[String] {}es foreach {   case "Goodbye" => System.exit  case x => println(x) }es.fire("Hello")es.fire("Goodbye") es.fire("Hello?")
}

It's at http://github.com/nafg/reactive

Hi, sorry I didn't respond earlier.I do not use continuations. Part of the reason Ingo uses them, if I'm not mistaken is to create a very clean and concise DSL. Also, he has done a ton of research on FRP and all different ways of implementing it. My library, on the other hand, is extremely simple in terms of implementation. As a result when you use it you are more explicit.As an example, suppose you want a signal s with the value if(x) y else z, where x, y, and z are themselves signals. Now with a pure pull implementation, you evaluate the expression when it's asked for, which makes things simple in a way, but on the other hand things can be calculated extra times. A push approach means the system has to know when a signal that another signal is dependent on has changed, so that it can avoid recalculating the latter when the former has not changed. Whether it recalculates it eagerly or lazily doesn't matter here. Now in the above example, when should s be recalculated? The correct answer is, it depends. It always depends on x, but in addition it could depend on either y or z, depending on x's value. With Ingo's scala.react, all you have to write isval s = Signal { if(x()) y() else z() }Every time s is evaluated, the system tracks which signals it read and updates internal information so that s is recalculated based on those signals. So it's doing a lot of convenient work behind the scenes.
With my simple library, in order to only evaluate the necessary signals you would write something like (without for comprehensions):val s = x.flatMap{ x=> if(x) y else z }
flatMap takes function f from a signal value to a signal. It returns a new signal which should be equivalent to the result of f applied to the last result of the signal flatMap was invoked on.
If you want the signal to have the value if(x) y+1 else z-1 then you'd writeval s = x.flatMap{ x=> if(x) {  y map {_ + 1}} else {  z map {_ - 1} }}


Internally the way it works is also very simple. Basically everything in the base Signal trait is built around its 'change' EventStream, with the addition of the concept of a current value. Then the Val subclass makes that value fixed, while the Var subclass supplies a mutator that fires an event in the change EventStream. (The names Val and Var are copied from Ingo.) Var itself has a subclass (temporarily named Clock_ as I explained) that mutates itself via java.util.Timer. EventStream is also quite simple. It simply holds a collection of listeners, which are functions that, whenever an event is fired, the functions are invoked with the value of that event.To prevent memory leaks, I used Ingo's pattern of Observers and WeakReferences -- see his paper. Basically there has to be an implicit Observer object in scope whenever you add a listener (or set something up which needs to be able to add one), which takes the responsibility of preventing the listener from being garbage collected (as long as the Observer stays in memory) by holding a reference to it. The EventStream itself only holds a WeakReference to the listener.
That's the whole concept. There are several collection-like combinators such as map, flatMap, filter, and foldLeft (that lets you respond to an event taking into an account the value calculated from the last event, same idea as a regular foldLeft). There is an implicit that lets you use a Signal as if it were an EventStream (returns its 'change' EventStream). And there is an EventStreamProxy trait which is to an EventStream as SeqProxy is to a Seq.
It is by no means a finish product, but thank G-d it seems to work quite well.

On Sun, May 30, 2010 at 9:28 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Hey! this looks pretty fun.   I'm also looking forward to Ingo Maier's work in scala.react, as I see a lot of good coming from this style of programming.

Are you also using scala's continuations under the hood?

On Thu, May 27, 2010 at 7:59 PM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:

Hello everyone.I started working on a very basic implementation of an FRP library.Ingo Maier's scala.react is almost finished, and my library is not really in competition with something that sophisticated. It's simpler and more verbose than his. The basic idea is to have an API similar to the collections API, with map, flatMap, foreach, etc.Here is some simple example usage (there's more, see sources):

import reactive._ object Main extends Application with Observing {
// Signals
val num = Var(10)  // create a mutable Signal[Int] val string = num map {_.toString}   // create a signal equivalent to applying toString on num// could also have written for(n <- num) yield n.toString
val clock = new Clock_(interval = 1000)  // the _ is due to a bug in eclipse on windows disallowing a file called CLOCK$. Fixed in newer eclipse milestones.
val string2 = for(s <- string; c <- clock) yield s + " " + clock.toString

// Events
string.change foreach println // change is an EventStream of the signal's type firing whenever it's updated // really ".change" could be left out due to an implicit
val es = new EventStream[String] {}es foreach {   case "Goodbye" => System.exit  case x => println(x) }es.fire("Hello")es.fire("Goodbye") es.fire("Hello?")
}

It's at http://github.com/nafg/reactive

On 28.05.2010 01:59, Naftoli Gugenheim wrote:
> Hello everyone.
> I started working on a very basic implementation of an FRP library.
> Ingo Maier's scala.react is almost finished, and my library is not
> really in competition with something that sophisticated. It's simpler
> and more verbose than his.
> The basic idea is to have an API similar to the collections API, with
> map, flatMap, foreach, etc.
> Here is some simple example usage (there's more, see sources):

What does FRP stand for?
And what is scala.react, is it hidden in some incubator?

Label {  text: bind textBox.text}var textBox = TextBox {}
would create a label that will dynamically reflect the contents of textBox.
This is very powerful for creating complex UIs, because rather than dealing with how the computer should do what you want, you just write what you want. In other words, rather than when events occur issuing imperative commands, you define the desired relationships as functions.
I highly recommend reading Ingo's paper, linked at the above page, or directly: http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf

On Wed, Jun 2, 2010 at 2:55 PM, Kai Meder <stuff [at] kai [dot] meder [dot] info> wrote:

On 28.05.2010 01:59, Naftoli Gugenheim wrote:
> Hello everyone.
> I started working on a very basic implementation of an FRP library.
> Ingo Maier's scala.react is almost finished, and my library is not
> really in competition with something that sophisticated. It's simpler
> and more verbose than his.
> The basic idea is to have an API similar to the collections API, with
> map, flatMap, foreach, etc.
> Here is some simple example usage (there's more, see sources):

What does FRP stand for?
And what is scala.react, is it hidden in some incubator?

On 02.06.2010 21:08, Naftoli Gugenheim wrote:
> FRP: Functional Reactive Programming
> scala.react is at http://lamp.epfl.ch/~imaier/
>
> FRP, in the loose sense, includes things
> like how JavaFX and Adobe Flex let you set a property to an expression
> that will automatically update the property when the value of the
> expression changes. For example (probably not the correct JavaFX
> syntax/names):
> Label {
> text: bind textBox.text
> }
> var textBox = TextBox {}
>
> would create a label that will dynamically reflect the contents of textBox.
>
> This is very powerful for creating complex UIs, because rather than
> dealing with how the computer should do what you want, you just write
> what you want. In other words, rather than when events occur issuing
> imperative commands, you define the desired relationships as functions.
>
> I highly recommend reading Ingo's paper, linked at the above page, or
> directly: http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf

Thanks for clarifying! I am currently working on my Master's Thesis with
perhaps a somewhat similiar Topic: DataFlow-Programming with the focus
on concurrency.
My current state of work is at:
http://github.com/hotzen/Thesis/tree/master/src/dataflow/

Going to read the papers right now, Thanks!

My favorite example in the real world is Excel (or Google Docs) spreadsheets with formulas: make a formula in one cell that's dependent on the value in a another cell (which itself might be a formula dependent on a another cell, etc.)

A very surprising number of accountants are very clever and accomplished FRP programmers specializing in the Excel environment.

Brian Maso

On Wed, Jun 2, 2010 at 12:08 PM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:

FRP: Functional Reactive Programmingscala.react is at http://lamp.epfl.ch/~imaier/
FRP, in the loose sense, includes things like how JavaFX and Adobe Flex let you set a property to an expression that will automatically update the property when the value of the expression changes. For example (probably not the correct JavaFX syntax/names): Label {  text: bind textBox.text}var textBox = TextBox {}
would create a label that will dynamically reflect the contents of textBox.
This is very powerful for creating complex UIs, because rather than dealing with how the computer should do what you want, you just write what you want. In other words, rather than when events occur issuing imperative commands, you define the desired relationships as functions.
I highly recommend reading Ingo's paper, linked at the above page, or directly: http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf

On Wed, Jun 2, 2010 at 2:55 PM, Kai Meder <stuff [at] kai [dot] meder [dot] info> wrote:

On 28.05.2010 01:59, Naftoli Gugenheim wrote:
> Hello everyone.
> I started working on a very basic implementation of an FRP library.
> Ingo Maier's scala.react is almost finished, and my library is not
> really in competition with something that sophisticated. It's simpler
> and more verbose than his.
> The basic idea is to have an API similar to the collections API, with
> map, flatMap, foreach, etc.
> Here is some simple example usage (there's more, see sources):

What does FRP stand for?
And what is scala.react, is it hidden in some incubator?

Yes, that's correct; it is related to workflow programming. Not that I know much about these topics but I read that somewhere.

On Wed, Jun 2, 2010 at 4:16 PM, Kai Meder <stuff [at] kai [dot] meder [dot] info> wrote:

On 02.06.2010 21:08, Naftoli Gugenheim wrote:
> FRP: Functional Reactive Programming
> scala.react is at http://lamp.epfl.ch/~imaier/
>
> <http://lamp.epfl.ch/~imaier/>FRP, in the loose sense, includes things
> like how JavaFX and Adobe Flex let you set a property to an expression
> that will automatically update the property when the value of the
> expression changes. For example (probably not the correct JavaFX
> syntax/names):
> Label {
>   text: bind textBox.text
> }
> var textBox = TextBox {}
>
> would create a label that will dynamically reflect the contents of textBox.
>
> This is very powerful for creating complex UIs, because rather than
> dealing with how the computer should do what you want, you just write
> what you want. In other words, rather than when events occur issuing
> imperative commands, you define the desired relationships as functions.
>
> I highly recommend reading Ingo's paper, linked at the above page, or
> directly: http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf

Thanks for clarifying! I am currently working on my Master's Thesis with
perhaps a somewhat similiar Topic: DataFlow-Programming with the focus
on concurrency.
My current state of work is at:
http://github.com/hotzen/Thesis/tree/master/src/dataflow/

Going to read the papers right now, Thanks!

Also, I'd appreciate whatever criticism anyone has to offer. :)

On Wed, Jun 2, 2010 at 12:59 PM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:

Hi, sorry I didn't respond earlier.I do not use continuations. Part of the reason Ingo uses them, if I'm not mistaken is to create a very clean and concise DSL. Also, he has done a ton of research on FRP and all different ways of implementing it. My library, on the other hand, is extremely simple in terms of implementation. As a result when you use it you are more explicit.As an example, suppose you want a signal s with the value if(x) y else z, where x, y, and z are themselves signals. Now with a pure pull implementation, you evaluate the expression when it's asked for, which makes things simple in a way, but on the other hand things can be calculated extra times. A push approach means the system has to know when a signal that another signal is dependent on has changed, so that it can avoid recalculating the latter when the former has not changed. Whether it recalculates it eagerly or lazily doesn't matter here. Now in the above example, when should s be recalculated? The correct answer is, it depends. It always depends on x, but in addition it could depend on either y or z, depending on x's value. With Ingo's scala.react, all you have to write isval s = Signal { if(x()) y() else z() }Every time s is evaluated, the system tracks which signals it read and updates internal information so that s is recalculated based on those signals. So it's doing a lot of convenient work behind the scenes.
With my simple library, in order to only evaluate the necessary signals you would write something like (without for comprehensions):val s = x.flatMap{ x=> if(x) y else z }
flatMap takes function f from a signal value to a signal. It returns a new signal which should be equivalent to the result of f applied to the last result of the signal flatMap was invoked on.
If you want the signal to have the value if(x) y+1 else z-1 then you'd writeval s = x.flatMap{ x=> if(x) {  y map {_ + 1}} else {  z map {_ - 1} }}


Internally the way it works is also very simple. Basically everything in the base Signal trait is built around its 'change' EventStream, with the addition of the concept of a current value. Then the Val subclass makes that value fixed, while the Var subclass supplies a mutator that fires an event in the change EventStream. (The names Val and Var are copied from Ingo.) Var itself has a subclass (temporarily named Clock_ as I explained) that mutates itself via java.util.Timer. EventStream is also quite simple. It simply holds a collection of listeners, which are functions that, whenever an event is fired, the functions are invoked with the value of that event.To prevent memory leaks, I used Ingo's pattern of Observers and WeakReferences -- see his paper. Basically there has to be an implicit Observer object in scope whenever you add a listener (or set something up which needs to be able to add one), which takes the responsibility of preventing the listener from being garbage collected (as long as the Observer stays in memory) by holding a reference to it. The EventStream itself only holds a WeakReference to the listener.
That's the whole concept. There are several collection-like combinators such as map, flatMap, filter, and foldLeft (that lets you respond to an event taking into an account the value calculated from the last event, same idea as a regular foldLeft). There is an implicit that lets you use a Signal as if it were an EventStream (returns its 'change' EventStream). And there is an EventStreamProxy trait which is to an EventStream as SeqProxy is to a Seq.
It is by no means a finish product, but thank G-d it seems to work quite well.

On Sun, May 30, 2010 at 9:28 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Hey! this looks pretty fun.   I'm also looking forward to Ingo Maier's work in scala.react, as I see a lot of good coming from this style of programming.

Are you also using scala's continuations under the hood?

On Thu, May 27, 2010 at 7:59 PM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:

Hello everyone.I started working on a very basic implementation of an FRP library.Ingo Maier's scala.react is almost finished, and my library is not really in competition with something that sophisticated. It's simpler and more verbose than his. The basic idea is to have an API similar to the collections API, with map, flatMap, foreach, etc.Here is some simple example usage (there's more, see sources):

import reactive._ object Main extends Application with Observing {
// Signals
val num = Var(10)  // create a mutable Signal[Int] val string = num map {_.toString}   // create a signal equivalent to applying toString on num// could also have written for(n <- num) yield n.toString
val clock = new Clock_(interval = 1000)  // the _ is due to a bug in eclipse on windows disallowing a file called CLOCK$. Fixed in newer eclipse milestones.
val string2 = for(s <- string; c <- clock) yield s + " " + clock.toString

// Events
string.change foreach println // change is an EventStream of the signal's type firing whenever it's updated // really ".change" could be left out due to an implicit
val es = new EventStream[String] {}es foreach {   case "Goodbye" => System.exit  case x => println(x) }es.fire("Hello")es.fire("Goodbye") es.fire("Hello?")
}

It's at http://github.com/nafg/reactive

Would you mind showing an example of how your project would be used?Thanks.

On Wed, Jun 2, 2010 at 4:16 PM, Kai Meder <stuff [at] kai [dot] meder [dot] info> wrote:

On 02.06.2010 21:08, Naftoli Gugenheim wrote:
> FRP: Functional Reactive Programming
> scala.react is at http://lamp.epfl.ch/~imaier/
>
> <http://lamp.epfl.ch/~imaier/>FRP, in the loose sense, includes things
> like how JavaFX and Adobe Flex let you set a property to an expression
> that will automatically update the property when the value of the
> expression changes. For example (probably not the correct JavaFX
> syntax/names):
> Label {
>   text: bind textBox.text
> }
> var textBox = TextBox {}
>
> would create a label that will dynamically reflect the contents of textBox.
>
> This is very powerful for creating complex UIs, because rather than
> dealing with how the computer should do what you want, you just write
> what you want. In other words, rather than when events occur issuing
> imperative commands, you define the desired relationships as functions.
>
> I highly recommend reading Ingo's paper, linked at the above page, or
> directly: http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf

Thanks for clarifying! I am currently working on my Master's Thesis with
perhaps a somewhat similiar Topic: DataFlow-Programming with the focus
on concurrency.
My current state of work is at:
http://github.com/hotzen/Thesis/tree/master/src/dataflow/

Going to read the papers right now, Thanks!

On 6/3/10 12:03 AM, Brian Maso wrote:
> My favorite example in the real world is Excel (or Google Docs)
> spreadsheets with formulas: make a formula in one cell that's dependent
> on the value in a another cell (which itself might be a formula
> dependent on a another cell, etc.)
>
> A very surprising number of accountants are very clever and accomplished
> FRP programmers specializing in the Excel environment.

The standard spreadsheet model is not FRP. It lacks first-class,
higher-order cells (to stay in Excel's terminology), it does not have
events and hence no way to combine these two. Much of FRP's
expressiveness (and complexity) comes from these two properties.

Cheers,
Ingo

>
> Brian Maso
>
> On Wed, Jun 2, 2010 at 12:08 PM, Naftoli Gugenheim > wrote:
>
> FRP: Functional Reactive Programming
> scala.react is at http://lamp.epfl.ch/~imaier/
>
>
> FRP, in the loose sense, includes
> things like how JavaFX and Adobe Flex let you set a property to an
> expression that will automatically update the property when the
> value of the expression changes. For example (probably not the
> correct JavaFX syntax/names):
> Label {
> text: bind textBox.text
> }
> var textBox = TextBox {}
>
> would create a label that will dynamically reflect the contents of
> textBox.
>
> This is very powerful for creating complex UIs, because rather than
> dealing with how the computer should do what you want, you just
> write what you want. In other words, rather than when events occur
> issuing imperative commands, you define the desired relationships as
> functions.
>
> I highly recommend reading Ingo's paper, linked at the above page,
> or directly:
> http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf
>
>
>
> On Wed, Jun 2, 2010 at 2:55 PM, Kai Meder > wrote:
>
> On 28.05.2010 01:59, Naftoli Gugenheim wrote:
> > Hello everyone.
> > I started working on a very basic implementation of an FRP
> library.
> > Ingo Maier's scala.react is almost finished, and my library
> is not
> > really in competition with something that sophisticated. It's
> simpler
> > and more verbose than his.
> > The basic idea is to have an API similar to the collections
> API, with
> > map, flatMap, foreach, etc.
> > Here is some simple example usage (there's more, see sources):
>
> What does FRP stand for?
> And what is scala.react, is it hidden in some incubator?
>
>
>

def main(...) = {

val v1 = new Variable[Int]

// waiting for v1 getting set, single-assignment!
flow { println( v1() ) }

flow { v1 := 42 }

// channel-mapper ch1 -> ch2
val ch2 = for (x <- ch) yield -1*x

// channel-consumer
flow {
for (x <- ch2) println(x)
}

// channel-producer
flow {
ch2 << 1
ch2 << 2
ch2 << 3
ch2 <<# // terminate channel, signaling end-of-stream
}
}

The Syntax was inspired by Boner's akka/actors DataFlow-Implementation.
The theoretic foundation is from the "cathedral"-book.

So long, Kai

On 03.06.2010 03:19, Naftoli Gugenheim wrote:
> Would you mind showing an example of how your project would be used?
> Thanks.
> Thanks for clarifying! I am currently working on my Master's Thesis with
> perhaps a somewhat similiar Topic: DataFlow-Programming with the focus
> on concurrency.
> My current state of work is at:
> http://github.com/hotzen/Thesis/tree/master/src/dataflow/
>
> Going to read the papers right now, Thanks!
>
>

Very nice!

On Thu, Jun 3, 2010 at 2:29 AM, Kai Meder <stuff [at] kai [dot] meder [dot] info> wrote:

def main(...) = {

 val v1 = new Variable[Int]

 // waiting for v1 getting set, single-assignment!
 flow { println( v1() ) }

 flow { v1 := 42 }

 // channel-mapper ch1 -> ch2
 val ch2 = for (x <- ch) yield -1*x

 // channel-consumer
 flow {
   for (x <- ch2) println(x)
 }

 // channel-producer
 flow {
   ch2 << 1
   ch2 << 2
   ch2 << 3
   ch2 <<# // terminate channel, signaling end-of-stream
 }
}

The Syntax was inspired by Boner's akka/actors DataFlow-Implementation.
The theoretic foundation is from the "cathedral"-book.

So long, Kai

On 03.06.2010 03:19, Naftoli Gugenheim wrote:
> Would you mind showing an example of how your project would be used?
> Thanks.
>     Thanks for clarifying! I am currently working on my Master's Thesis with
>     perhaps a somewhat similiar Topic: DataFlow-Programming with the focus
>     on concurrency.
>     My current state of work is at:
>     http://github.com/hotzen/Thesis/tree/master/src/dataflow/
>
>     Going to read the papers right now, Thanks!
>
>

Sorry for bumping, just for those interested...
I updated all tests:
http://github.com/hotzen/Thesis/tree/master/tests/dataflow/tests/

Cheers, Kai