posted by exoteric

posted by tomkirbygreen

C

posted by Charles

posted by staceyw

posted by staceyw

Also intresting to think about this in terms of a UI framework.  Where the framework itself has one giant IObserable which sends a new value every time the mouses moves or keyboard is pressed, and it hands off to all its children .Where(...) verions of the giant IObserable that filter for just its selected area of the screen or currently selected child (which then wraps its children in another .Where).  In the end you dont need to even test do any hitbox testing or anything, everything just flows down stream.  I spose most UI frameworks like WPF already do this with thier visual tree's just invoking methods on a child of a known type (like UIElement), but when you look at the 100's of On... overrideable method calls, you got to wonder if filtering only what you need might be a better option.  Where they dont have to keep extending the base class to add additional method calls, and instead add new derived event types that return more specific infromation if you want that extra info.  Or say your a team like Microsoft Surface that has some specific type of "new" interaction events you want to pass to your children based on specific proprietary hardware.  In the current WPF, this is very hard/impossible (I think they derived thier own UIElement type and force all thier children had to derive from that to get the new events).

posted by cdwatkins

I wonder if it wouldn't make sense to systematically and automatically retrofit all of .Net with these types, that is, using some naming convention, simply inject one IObservable property for every event. If I remember correctly, you're just using an event and holding a subscriber delegate to the event and on dispose you just remove the same delegate. So it should be a mechanical process to retrofit. This way we can also have this retrofitted to good old WF.

Also, it would seem like this would have some interesting deeper implications for concurrency and coordination if we have parallel events going on and we coordinate them with these query combinators, hmm...

posted by exoteric

posted by cdwatkins

Charles: Maybe you should just rename the posts to Reactive Extensions for .Net: ...... to defuse confusion. Or I should just get to work now heh...

posted by exoteric

what is crucial though is interop with exsisting stuff.. tasks for example, or the event based calls in silverlight (not a big fan of those) or begin/end invoke, or events..

there are stories for most of them but some are better than others, converting an event to an iobservable is somewhat clunky and involves magic strings (although there is type safe way of doing it to)

i think what we'll see is a bunch of extension method libraries for getting iobservable versions of various events.. its to bad they didnt have this stuff when wpf was created

posted by aL_

To be clear, "Reactive Extensions" is not officially official, but is the direction the team + marketing is going. I will leave the title as is for historical reasons You will learn more about this technology as it grows. At some point, an official anouncement of some kind will emerge and a new name will be born.

C

posted by Charles

posted by exoteric

edit: the points regarding let at the end were interesting, but perhaps not really discussed properly, ie.. no practical example.

Great video two parter tho, good ending .

posted by stevo_

I also wish you'd talk more about Let. How is that implemented? Does it give you lazy computation? E.g. Haskell lets your write:

  zero = let x = x in 0

And you won't get an infinite loop. Does Let allow somethign similar?

Good stuff!

posted by Justin Bailey

IObservable<Event<MouseEventArgs>> mouseMoveEventObservable = Observable.FromEvent<MouseEventArgs>(myControl, “MouseMove”); mouseMoveEventObservable.Subscribe(...);

So looking at this it's not the sweetest syntax you could arrive at, but here the lacking use of type-inference is a culpit as well, so we make it a bit sweeter

var mouseMoveEventObservable = Observable.FromEvent<MouseEventArgs>(myControl, “MouseMove”); mouseMoveEventObservable.Subscribe(...);

Then finally the solution we would have wanted from the outset

myControl.MouseMove.Subscribe(...);

Clearly there is some syntactic overhead which will repreat itself in each and every program. Whether one actually cares about something like this is a different matter.

posted by exoteric

I have a question: you mention that SelectMany "merges" event streams, and you have to use until make sure that you stop listening when a new event comes in (in the dictionary suggest example). I cannot think of an example where you'd NOT want to use until. So why isn't this the default behavior for SelectMany? Can you give an example where you'd want to have SelectMany to merge the event streams instead of switching to the most current one?

posted by Jules.dot

If you do not want the side-effect of reading from the console twice:

Console.WriteLine(Console.ReadLine() + Console.ReadLine());

you do it once by assigning the result to a local variable

{ 
         var s = Console.ReadLine();

 Console.WriteLine(x+x);

        }

In Haskell terms Let  is actually very close to bind :: IO a -> (a -> IO b) -> IO b in the IO monad; but in C# the IO monad is the ambient monad so you do not see it in the type.

posted by head.in.the.box

Of course it would be nice if there would be direct language support for this, but in general when you can do something "good enough" using a library, I am not sure that you want to increase the feature footprint of the language even more.

posted by head.in.the.box

In the "marble diagram" below, you want to collect both P1 and P0 that result from B0 and B1, even though they came back out of order:

--B0------------B1------------------------->

             |                       |

             --------------------------P0.

                                     |                     |

                                     -----P1.        |

                                                |          |

       ------------------------P1----P0------------->

posted by head.in.the.box

The reasons why observable streams work so well in this context (and answers your question affermatively) is eloquently explained in this paper http://www.irisa.fr/asap/intranet/the-many-faces-of-publish-subscribe.pdf/

posted by head.in.the.box

public static IObservable<Event<MouseButtonEventArgs>> GetMouseLeftButtonDown(this UIElement that) { return Observable.FromEvent<MouseButtonEventArgs>(that, "MouseLeftButtonDown"); } 

The compositional nature of these things ("IE" & "IO") is very inspiring. Looking forward to the beta 2 drop, hopefully with Rx.

It'll also be interesting to see the extension method proliferation in support of these new types. At least if a legacy API does not support it, one can always add support oneself.

posted by exoteric

http://research.microsoft.com/en-us/projects/ame/ame-yielding-montanari.pdf

posted by staceyw

C

posted by Charles

posted by MarcinNajder

DateTime.Now should be an IObservable<DateTime>!

posted by exoteric

Is there an expert-to-expert episode out there where CCR (Concurrency and Coordination Runtime) is compared to Rx?

I would like to know of a specific similarities. May be Erik, from his functional and Rx perspective, can lead CCR discussion?

I've heard CCR is very fast and I would like to know how Rx will fit into this concurency picture.

Can I apply both CCR and Rx? What would the best use case for CCR and Rx? Where one is better/worse than the other for concurrent apps?

I watched how MySpace implemented CCR into their code, it was very interesting.

posted by ivan_

C

posted by Charles

posted by head.in.the.box

Coming from the videogames industry I got fascinated by functional reactive programming, and started learning Haskell and FRP a couple of years ago.

C# is still my favorite language for writing production software, and it's great to see that my studies of Haskell & FRP will now help me write better reactive C# code. I did not expect this FRP hobby of mine to actually be useful in C#! So many thanks guys!

Now the FRP systems I looked at (Fran, Yampa, Fruit, Reactive) are side effect free; it will be interesting to see how easy it is to master Rx in the presence of side effects.

One thing that seems unclear to me is if Rx uses times at which events happen, and how they are sorted. For example, in Conal Elliott's Reactive library you have a merge function that merges two event streams, ordering them by occurrence time, left-biased if two events happen at exactly the same time.  Not sure how Rx handles that; I guess because it embraces side effects, it doesn't really care, since it is fully push based, what is pushed first is handled first?

Really looking forward to play with it!

posted by Ziriax

Regarding the problem with receiving non linear events and solving this with the until, how does this work when the observers are in distributed system like a cloud environment where the until would need to be able to block/dispose of processes on other physical/virtual machines? Unless the cloud is already doing the thread merging and I just haven't found out yet.

posted by danvonnewman

Wes Dyer dude u rock too bro ... and I am jealous u get to work with Erik

THANKS again Charles/Erik for putting togather the E2E series and allowing us, "the App Develpers" really learn more about language design and how stuff is actually implemented behind the scenes.

p.s.  I introduced these videos to my hard core Java developers and they are slowly but surely getting warmed up to the beauty of C# and .NET in general just love it.

posted by Mohamoud