Tom Lokhorst

Programming Streams of Coincidence with Join and GroupJoin for Rx
Jan 26, 2011 at 6:46 AM
If I understand this correctly, people entering/leaving a room can be modeled like so:
```
IObservable<Person> peopleEnteringRoom = ...;

class Person
{
  public IObservable<object> LeaveRoom;
  ...
} 
```
In this case, I don't have any information to communicate when a person leaves the room, that's why I chose IObservable<object>. I've implemented a person leaving as such:
```
person.LeaveRoom.OnNext(null);
person.LeaveRoom.OnCompleted(); 
```
Is this the correct, or recommended, way to implement this?
Juan Chen and Nikhil Swamy: FINE, Functional Programming for End-to-End Security Verification
Dec 11, 2009 at 3:33 AM

Interesting!

The type of fread looks a bit like a dependent type. Since the third type depends on the value of the first argument. Although, since u is only used in the predicate part of the "type", that might not be true.

Is FINE depedently typed?
Reactive Extensions API in depth: Zip
Dec 08, 2009 at 1:19 PM

Great!

Is there also a combinator that will duplicate the latest of either the left or the right stream? Such that the result is as fast as the fastest stream (after the initial value has been yielded).

If it doesn't exist it can probably be implemented using SelectMany and Until.
Reactive Extensions API in depth: Zip
Dec 08, 2009 at 12:11 PM

Cool, I was waiting for this video!

But what if xs produces faster than ys? Will Zip start caching or will it drop xs and always match up the last x and the last y?

Reactive Extensions API in depth: Primitives

Nov 24, 2009 at 1:39 PM

Bottom isn't really a type. I'd say something like:

never :: Subject a
empty :: Subject a
return :: a -> Subject a
throw :: Exception e => e -> Subject a

Where of course:

instance Monad Subject where 
 ...

Reactive Extensions API in depth: Primitives
Nov 24, 2009 at 12:25 PM
Does Return call OnNext after someone subscribes, or calls it OnNext during the call to Subscribe? If I call Subscribe, I get back an IDisposable, but do I get the change to call Dispose before the Observable starts pushing values?

In other words, what if I want this method:
```
IObservable<T> ToObservable<T>(this IEnumerable<T> xs)
{
  return new IObservable<T>()
  {
    IDisposable Subscribe(IObserver<T> obs)
    {
      foreach (var x in xs)
        obs.OnNext(x);
      obs.OnDone();
      return someDisposable(); // Don't know how to implement
    }
  }
}
```
Can I unsubscribe from the IObservable before or during the series of OnNext calls?
Reactive Extensions API in depth: Until and WaitUntil
Nov 23, 2009 at 12:43 AM

Just get things clear, is the following true?

WaitUntil(xs, ys) does not propagate the exception from ys if it happens before ys starts producing values, but it will propagate after ys started producing values?

Or, the exception propagates after xs and ys started producing values?
C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals Chapter 7 of 13
Nov 12, 2009 at 3:29 PM
I'd say its easier to implement takeWhile using foldr:
```
takeWhile p = foldr (\x xs -> if p x then x : xs else []) []
```
Also, foldr most definitely does not consume the whole list before producing a result. Take this definition:
```
foldr :: (a -> b -> b) -> b -> [a] -> b foldr f z [] = z foldr f z (x:xs) = f x (foldr f z xs)
```
As you can see in the cons case; foldr calls f with x and the result of a recursive call.
However, since Haskell is lazy, f gets executed before the result of the recursive call is computed. If f decides to never inspects its second argument, the recursive call will never be evaluated. So that's why you can do: takeWhile (<4) [0..]

However, you are right about foldl.
```
foldl :: (a -> b -> a) -> a -> [b] -> a foldl f z [] = z foldl f z (x:xs) = foldl (f z x) xs
```
foldl first recurses, before executing the f function that produces the result value.

So calling the takeWhile', defined below, with an infinite list will result in an infinite computation.
```
takeWhile' p = foldl (\ys x -> if p x then ys ++ [x] else ys) []
```
C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals Chapter 7 of 13
Nov 12, 2009 at 12:30 PM

Right

To be clear to everyone: What I'm saying is that the equalities are wrong. The first definition is perfectly fine.

Also sylvan: Very nince demo of QuickCheck, and a good thing you put a type signature on prop_Concat.

When I started using QuickCheck I didn't do that and GHCi defaulted that kind of a function to: prop_Concat :: [()] -> [()] -> Bool

So the tests all ran OK and I ended up submitting a wrong solution to an exercise to my teacher...
C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals Chapter 7 of 13
Nov 12, 2009 at 11:53 AM
The equational reasoning part on the append operator (++) is wrong. This is what Erik wrote:
```
xs ++ ys = foldr (:) ys xs ≡ { 1 } (++) ys xs = foldr (:) ys xs ≡ { 2 } (++) ys = foldr (:) ys ≡ { 3 } (++ ys) = foldr (:) ys ≡ { 4 } (++) = foldr (:)
```
This contains several errors:
- The first equality is wrong because the arguments are flipped: xs ++ ys ≡ (++) xs ys
- The second equality is true, although since the arguments of append are flipped, the function doesn't have the correct behaviour
- The third equality is wrong because it's flipping the arguments again. Although actually, (++ ys) isn't a valid way to define a function, so you can't write this down in Haskell. But if this were valid Haskell, the the behaviour of this append operator would be correct again.
- The fourth equality is wrong again because it once again flips the arguments.
A correct way to define append would be:
```
(++) = flip (foldr (:))
```
Having said all that, I really like this series.

Keep on going Erik!

See more comments…

Staff