Comments

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?

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?

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.

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?

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 
 ...

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?

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?

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) []

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...

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!