wishing of reactive programming in ruby

[ashishwave]

ruby integrates power of functional programming from lisp , purest OO
from smalltalk, prototype oriented power from self etc etc into one
single language

i just was wondering that whether the heavy developers/users of
reactive languages like kanaputs or reactive-C etc will ever get
reactive features in ruby.

in kanaputs, If the variable 'c' is defined as c = a + b; and if the
reactivity of 'c' is set (c.reactive = true, then each time the
value of 'a' or 'b' changes then the value of 'c' is updated as the
result of the addition


bye
Ashish
(e-mail address removed).

 

[Trans]

ruby integrates power of functional programming from lisp , purest OO
from smalltalk, prototype oriented power from self etc etc into one
single language

i just was wondering that whether the heavy developers/users of
reactive languages like kanaputs or reactive-C etc will ever get
reactive features in ruby.

in kanaputs, If the variable 'c' is defined as c = a + b; and if the
reactivity of 'c' is set (c.reactive = true, then each time the
value of 'a' or 'b' changes then the value of 'c' is updated as the
result of the addition

That's interesting --a form of rational programming (like Prolog).

But I think it is far outside the scope of Ruby's design.

T.

 

[benjohn]

That's interesting --a form of rational programming (like Prolog).

But I think it is far outside the scope of Ruby's design.

I'm about to go home. Damn.

I've been very interested in reactive programming for about 10 years,
although I've never heard of it reffered to as such. The Empirical
Modelling group at Warwick University did a lot of work on it in a
language called EDEN. They called it Definative Programming (think
reactive is a much better name, as it happens).

It's entirely possible to build a library in an imperative language that
will provide reactive programming capabilities. I've previsouly used a
similar idea for a GUI application in C++, and it made implementation of
pretty complex change propagation very easy.

My recent thinking is that reactive programming shares a great deal with
software transactional memory, and could share a lot of infrastructure.

Something the Empirical Modelling group at Warwick found was that
Reactive Programming is also very useful for making systems that are
composable. They could often take a few models they'd built, and easily
combine them, make a few other changes, and come up with a new useful
model. This is curious because composability is also a strong advantage
of STM.

My personal opinion is that reactive programming is _the_ pattern for
building any kind of interactive software (ie - something that doesn't
just process a batch of data, but reacts to user initiated changes to
its state, or changes from an external system). As an approach, it's got
a lot of overlap with:

Model View Controller pattern and Observer, etc,
Spreadsheet change propagation,
Database Triggers and propagation.

Basically, you just don't need to think about the complexity that's
caused by propagating changes through a program. It really is pretty
dramatically cool

Cheers,
Benjohn

 

[Dan Zwell]

i just was wondering that whether the heavy developers/users of
reactive languages like kanaputs or reactive-C etc will ever get
reactive features in ruby.

in kanaputs, If the variable 'c' is defined as c = a + b; and if the
reactivity of 'c' is set (c.reactive = true, then each time the
value of 'a' or 'b' changes then the value of 'c' is updated as the
result of the addition


bye
Ashish
(e-mail address removed).

I haven't used reactive languages, but can't this be emulated by using
methods and instance variables?
To emulate:
c = a+b; c.reactive = true
use:
def c; @a+@b; end

Then you could pretend c was a variable. To reset the value, just
redefine c(). It would be simpler if all variables were methods, not
instance variables. If you wanted, you could write a wrapper for that,
so that set_reactive("c", "a + b") or set_reactive("c=a+b") would wrab a
call to class_eval or instance_eval that defined the method as "def c;
a() + b(); end". If you did this, however, you could never set a, b, or
c by simple assignment.

A big problem might be parsing the input. I could elaborate on some
suggestions. (I wrote code that converts standard arithmatic notation to
reverse polish notation, which is very easy to evaluate. You could also
do a simpler scheme like not allowing more than one operation.) Let me
know if you are interested. And let me know if I'm not grasping reactive
programming correctly--I've never used it.

Dan

 

[James Edward Gray II]

I've always been a partisan of loosely-coupled systems that use
idempotent
messaging. I'm still hopeful that such a thing will come to Ruby.

Are you aware of the Omnibus Concurrency Library?

http://rubyforge.org/projects/concurrent/

(This in fact was precisely the reason that the EventMachine
library was developed, and it's still on the roadmap.)

To someone like me who has been looking at Erlang recently, this is
very interesting. Can you share and of your plans for how
EventMachine might evolve into this? I'm just curious.

James Edward Gray II

 

[Robert Klemme]

I haven't used reactive languages, but can't this be emulated by using
methods and instance variables?
To emulate:
c = a+b; c.reactive = true
use:
def c; @a+@b; end

Then you could pretend c was a variable. To reset the value, just
redefine c().

I guess there is one major drawback of your approach: it will break as
soon as systems grow to a reasonable size because whenever you access a
variable you have to reevaluate the complete formula. I guess any
implementation that offers reasonable performance will have to do some
kind of dependency tracking and caching of current values.

The interesting question is how could this be done in Ruby so it's
nicely integrated or a clean DSL? For seamless integration you would
have to be able to redefine (or hook into) variable access (which would
be a nice feature btw). You also would need enhanced code inspection in
order to be able to determine what other variables a variable depends on.

It would be simpler if all variables were methods, not
instance variables. If you wanted, you could write a wrapper for that,
so that set_reactive("c", "a + b") or set_reactive("c=a+b") would wrab a
call to class_eval or instance_eval that defined the method as "def c;
a() + b(); end". If you did this, however, you could never set a, b, or
c by simple assignment.

Yep. Interesting topic nevertheless.

Kind regards

robert

 

[M. Edward (Ed) Borasky]

Yes, I took a close look at the Erlang concurrency verbs (spawn, and the
verbs for sending messages to Erlang "processes") and I sketched out an
implementation of them above the standard EventMachine. I'd like to use
Stomp for message-passing across "processes" that are in different OS-level
processes or on different machines. When this gets done, current plans are
to release it as EventMachine version 0.9.0.

Any ideas, counterarguments, or offers to help?

Well, I'll certainly offer to *test* it.

 

[Clifford Heath]

I'm about to go home. Damn.
They called it Definative Programming (think
reactive is a much better name, as it happens).

A strongly related, but possibly even more advanced technique is called
Constraint Logic Programming, CLP. It's been around since around 1981
or earlier. Doing it with real numbers (so-called CLP/R) has a lot of
hardcore difficulties, but it's being used in high-end architectural
design packages, for example. In such tools, the formula for the size
of a beam required to span two walls and support a particular load is
dynamically recalculated as you vary the wall spacing, just to give you
an idea of why you might want such a language.

Clifford Heath.

 

[Ezra Zygmuntowicz]

A strongly related, but possibly even more advanced technique is
called
Constraint Logic Programming, CLP. It's been around since around 1981
or earlier. Doing it with real numbers (so-called CLP/R) has a lot of
hardcore difficulties, but it's being used in high-end architectural
design packages, for example. In such tools, the formula for the size
of a beam required to span two walls and support a particular load is
dynamically recalculated as you vary the wall spacing, just to give
you
an idea of why you might want such a language.

Clifford Heath.

You will probably find this interesting: http://www.flapjax-lang.org/

Cheers-
-- Ezra Zygmuntowicz
-- Founder & Ruby Hacker
-- (e-mail address removed)
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)

 

[Simon Krahnke]

in kanaputs, If the variable 'c' is defined as c = a + b; and if the
reactivity of 'c' is set (c.reactive = true, then each time the
value of 'a' or 'b' changes then the value of 'c' is updated as the
result of the addition

In a simple and slow implementation you can just put expression in a
string, and eval it everytime the value is needed.

mfg, simon .... l

 

[Stefan Rusterholz]

ruby integrates power of functional programming from lisp , purest OO
from smalltalk, prototype oriented power from self etc etc into one
single language

i just was wondering that whether the heavy developers/users of
reactive languages like kanaputs or reactive-C etc will ever get
reactive features in ruby.

in kanaputs, If the variable 'c' is defined as c = a + b; and if the
reactivity of 'c' is set (c.reactive = true, then each time the
value of 'a' or 'b' changes then the value of 'c' is updated as the
result of the addition


bye
Ashish
(e-mail address removed).

Not the same, probably rather slow, but hey:

class Expression < BlankSlate
def initialize(&expression)
@expression = expression
end

def method_missing(*a, &b)
@expression.call.send(*a, &b)
end
end

a = 1
b = 2
c = Expression.new { a + b }
c + 3 # => 6
a = 5
c + 3 # => 10

Have fun ;-)

Regards
Stefan

 

[benjohn]

*snip*

I've always been a partisan of loosely-coupled systems that use
idempotent
messaging. I'm still hopeful that such a thing will come to Ruby. (This
in
fact was precisely the reason that the EventMachine library was
developed,
and it's still on the roadmap.)

*snip*

If you've got some links you could share about idempotent messaging, I'd
like to read them. The hits I'm getting seem to be about interprocess
protocol, rather than an approach that you'd also use intraprocess.

 

[Martin DeMello]

ruby integrates power of functional programming from lisp , purest OO
from smalltalk, prototype oriented power from self etc etc into one
single language

i just was wondering that whether the heavy developers/users of
reactive languages like kanaputs or reactive-C etc will ever get
reactive features in ruby.

in kanaputs, If the variable 'c' is defined as c = a + b; and if the
reactivity of 'c' is set (c.reactive = true, then each time the
value of 'a' or 'b' changes then the value of 'c' is updated as the
result of the addition

http://common-lisp.net/project/cells/ is an interesting common lisp
project in that area

martin

 

[Brad Phelan]

ruby integrates power of functional programming from lisp , purest OO
from smalltalk, prototype oriented power from self etc etc into one
single language

i just was wondering that whether the heavy developers/users of
reactive languages like kanaputs or reactive-C etc will ever get
reactive features in ruby.

in kanaputs, If the variable 'c' is defined as c = a + b; and if the
reactivity of 'c' is set (c.reactive = true, then each time the
value of 'a' or 'b' changes then the value of 'c' is updated as the
result of the addition


bye
Ashish
(e-mail address removed).

I think this may give you some ideas. A Reactive object
has a number of reactive objects it depends on as well
as a block to calculate it's own value. The self value
is calculated lazily and cached. It is only recalculated
when an object it depends on set's it's dirty flag
by calling notify.


class Reactive

# On change of value dependants are notified
# of updates
def value=(val)
@value=val
@depends.each do |d|
d.notify
end
end

# Add d as a listener
def notify_me d
@depends << d
end

# Get the cached value unless the
# dirty flag has been set then
# recalc the value from the block
def value
if @block && @dirty
argv = []
@args.each do |a|
if a.respond_to? :value
argv << a.value
else
argv << a
end
end
@value = @block.call *argv
end
@dirty=false
@value
end

# Notify this object that at
# least one dependant has changed.
def notify
@dirty=true
end

# Init the class with the dependant
# reative variables and a block to
# evaluate to compute the value
# of this object.
def initialize *args, &block
@depends = []
if block_given?
@args = args
@block = block
@args.each do |a|
a.notify_me self
end
else
# This is a literal
@value = *args
end
@dirty=true
end

end


a = Reactive.new(10)
b = Reactive.new(20)
c = Reactive.new a,b do |_a,_b|
_a + _b
end
d = Reactive.new b,c do |_b,_c|
_b + _c
end


vars = {:a=>a,:b=>b,:c=>c,:d=>d}

vars.each do |k,v|
puts "#{k} #{v.value}"
end

puts "------------------"

a.value = 40
vars.each do |k,v|
puts "#{k} #{v.value}"
end

------------------

Output is

:!ruby reactive.rb
c 30
d 50
a 10
b 20