posted by Justin Bailey

I was SO glad EriK asked about the TeXBook. It was disappointing that Larry only worked with it for a summer though - TeX is a mind blow.

I suspect Erik is a TeX freak - am I right? Maybe he'd do a deep dive on it

posted by Justin Bailey

posted by Justin Bailey

Caller Info attributes: pretty neat. Immediately I want to know why "CallerType" is missing. "CallerMemberName" just begs for it?

Another question: Will the attributes be available anywhere but optional parameters? Why not allow them on any assignment? Then I can write:

var line = -1;
Console.WriteLine("Printing at line {0}!", [CallerLine] line = 0);

I know I can create wrapper method but it seems like ceremony.

Don't get me wrong tho, I am thrilled to see these features. Maybe I'm just bikeshedding .

posted by Justin Bailey

posted by Justin Bailey

Greg Morrisett's papers are worth reading. I found "TALx86: A Realistic Typed Assembly Language" to be the most accessible (http://www.cs.cornell.edu/talc/papers.html).

Atsushi Ohori wrote a paper that treats typed machine languages as proof systems. Very abstract but impressive too: "A Proof Theory for Machine Code" (http://www.pllab.riec.tohoku.ac.jp/~ohori/research/LogicalMachineRevOct2005.pdf).

Unfortunately none of the research compilers or languages (including Cyclone) evolved into something 'real'. Maybe Microsoft will release "Verified C#" with Visual Studio 2011???

Thanks for putting these two on, really cool to see!

posted by Justin Bailey

Thanks for posting this!

posted by Justin Bailey

posted by Justin Bailey

  http://strictlypositive.org/calculus/

posted by Justin Bailey

Good stuff as always!

posted by Justin Bailey

Great start to a very promising series, thank you! 

posted by Justin Bailey

Have you seen Conal Elliot's paper "Beautiful Differnetation"? It doesn't talk about co- or contra-variance, but he does go over a lot of the same differentation you & Erik covered in your paper:

   http://conal.net/blog/posts/paper-beautiful-differentiation/

posted by Justin Bailey

posted by Justin Bailey

Hope this post isn't too late. I'm reading through the attached paper and having trouble in the "Transformations, Jacobians" section (and in the example that follows). your definitions of "bold x" and "bold y" look infinitely recursive to me:

  x = X . y

  y = Y . x

In the example, I find the same thing when defining x1 (squiggle) and x2 (eta). They are defined in terms of y1 (rho) and y2 (theta). y1 and y2 are then defined in terms of x1 and x2!

I am sure I am thinking too operationally here but any enlightment would be appreciated!

Justin

posted by Justin Bailey

I'd say these lectures are geared towards people who know  C#, VB.Net, Java,etc. Mapping back to C# helps ground the concepts. Haskell is like alien technology. It can make things a lot clearer (and more relevant) to correlate it with something you already understand. That's kind of true when learning anything new in fact ...

In any case you can always buy the book at a discount and learn Haskell from the ground up. That's what it was written for.

posted by Justin Bailey

OK - done pimping now

Justin

posted by Justin Bailey

  http://cheatsheet.codeslower.com/

posted by Justin Bailey

  http://www.haskell.org/visualhaskell/

BUT the sources are available and I wish someone would update it ...

  http://darcs.haskell.org/vshaskell/

Justin

posted by Justin Bailey

posted by Justin Bailey

When I started learning Haskell a lot of the "elegant" solutions really bothered me - I couldn't understand them and they seemed obscure. They used many nested function definitions or class instances which tied my brain in knots. I slowly realized, though, that once you knew the definition of a function, you could forget it. The details didn't matter - you just needed to be reminded of its basic operation and type. I think that Haskell's purity (in the technical sense) allows this much more than languages w/ side-effects. Its very easy to extract a chunk of code and wrap it up in a small definition w/o changing the behavior of your program.

Let me illustrate with calculus.  These two things say the same thing, but one is more suitable for a beginner while the other is obvious to anyone familiar with the notation:

  "Consider a parabola. Look at the slope between two points on the curve. Now move the points closer together. Consider how the slope changes. As the points get closer and closer together, the slope of the line between them will converge on 2 * x, no matter where  you are on the curve"

Or

  "d (x ^ 2) / dx = 2 * x"

I would expect the "tricks" that Erik promised to show would be along these lines - "tricks" that make our programs more flexible while at the same time "easier" to understand (once you know the basics).

posted by Justin Bailey

I think my only suggestion would be to check if s is empty first, then you can rewrite:

public static IEnumerable<T> Qsort1<T>(this IEnumerable<T> s) where T : IComparable<T>
{

    return ! s.Any() ? Enumerable.Empty<T>() :
        from x in s.Take(1)
        let xs = s.Skip(1)
        let a = xs.Where(y => y.CompareTo(x) <= 0).Qsort1()
        let b = xs.Where(y => y.CompareTo(x) > 0).Qsort1()
        select a.Concat(s.Take(1)).Concat(b);
}

But I don't know if that is allowed syntax.

posted by Justin Bailey

One comment - though you are focusing on Haskell, please keep it tied to C# (e.g., "here's how to do it in C#") and keep it practical. By comign back to C#, unfamiliar concepts look familiar. By keeping it practical, we'll see how this stuff can really be used. Haskell - not just for Fibonacci anymore! OK that's a bit facetious.

As for the homework, here is my solution. I basically transcribed the Haskell version shown. I am sure it can be prettier:

public static IEnumerable<A> QuickSort<A>(IEnumerable<A> vals)
            where A : IComparable<A>
        {
            if (vals.Skip(1).IsEmpty())
                return vals;
            else
            {
                A pivot = vals.First();
                var rest = vals.Skip(1);
                var left = from x in rest
                           where x.CompareTo(pivot) <= 0
                           select x;

                var right = from x in rest
                            where x.CompareTo(pivot) > 0
                            select x;

                return QuickSort(left).Concat(vals.Take(1)).Concat(right);
            }
        }

Note : IsEmpty is an extension method which tests if a sequence is empty. I can't believ that is not already defiend in the framework so I am sure i missed it.

I particularly like the end part, where I concatenate the single pivot value into the sequence:

  return QuickSort(left).Concat(vals.Take(1)).Concat(right);

Since the list is not empty, I know I can take the first value and stick in the right place. My base case also takes advantage here:

           if (vals.Skip(1).IsEmpty())
                return vals;
            else

                 ...

If the sequence given only has one element, I just return it unchanged and it automatically goes in the right spot. Thank you recursion!

Full source code & VS2008 project available on github.

Justin

posted by Justin Bailey

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

1) SpotAgent allows many subscribers; RiskAgent only one -- That says the Subscribe method isn't giving enough information (and the IObservable interface isn't rich enough). I wonder how you could indicate that a given Observable allows many observers vs. one?

2) One problem that Erik points out with IEnumerable is the "subscriber" which calls GetNext() has no control over how long the "publisher" take to return the next value. I think IObservable reverses this problem. That is, the "publisher" (IObservable object) has no control over how long given "subscriber's" (IObserver) OnNext method will take to complete. You can see this issue in the Tick() methods for SpotAgent and RiskAgent.

Does the composobility of IObservable/IObserve help solve this problem?

Looking at your code definitely exposes some issues that I'm sure Erik's team has faced when developing their library.

posted by Justin Bailey

A question: The scope of the  IDisposable object returned by Subscribe() was unclear to me. Erik implies you can put it in a using statement, like a normal IDisposable. But the lexical scope of the IDisposable returned seems much different than the lifetime ("runtime scope"?) of the IObserver you pass in. For example, the using statemetn with IDisposable for files is pretty obvious:

  using(fs = new Stream("somefile.txt"))   
  {     
    // ... do work on fs ...   
  } // fs is closed and disposed. 

But in the IObserver case, I don't think the using statement's scope is appropriate for indicating you don't care about events anymore. Using the autocomplete example above:

using(q.Subscribe(suggestions => ... ))
{
  // ???
} 

What happens in the body of the using statement? All the work seems to occur in the lambda passed to Subscribe. If I understood correctly, as soon as we leave the scope of the using statement, my lambda stops receiving events. Hmm, I bet the object implementing IDisposable has the secret sauce for the reactive framework. Maybe it has a method for testing for conditions and will "yield" until the condition is met? For example if I had another observer which looked for ENTER or TAB on the textbox and indicated that a selection was made, maybe it would let me write this code:

class KeyObserver :  IObserver<...>
 {
    publi c bool SelectionMade()
 }

KeyObserver key = ...;

using(cntrl = q.Subscribe(suggestions => ... ))
{
   if(! key.SelectionMade())
     sleep;
} 
// selection has been made and we stop listening to suggest events

Hopefully that makes some sense. It looks like the beginnings of a way to do reasonable event based programming. Apologies for answering my own question but glad to hear if I'm on track ...

Two other notes:

• Check out the AsyncEnumerator library from Jeffrey Richter. He leveraged enumerators and iterators to do something similar, but I think his solution still has an "inversion of control" problem where you need to write the code to drive the enumerator. A recent article can be found at http://msdn.microsoft.com/en-us/magazine/cc721613.aspx
• Erik mentioned a paper by Phillip Wadler called "The essence of monads" or similar. I think he meant "The essence of functional programming" (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.9516).

Great stuff, get me this code!

Justin

posted by Justin Bailey