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:

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!

You seem to be a troll so it's hard to answer in a cooperative spirit. Moving on ...

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.

There is Visual Haskell, but it's very out of date. It targest VS 2005, does not use the Managed Package Framework (i.e., it extends VS using C++ rather than .NET), and its married to a really old version of GHC:

I agree regarding obscure code, or anything written in C (** duck **), but of course I don't think that is the case here.

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

Very nice solution! How does it deal with empty sequences? I assume Take and Skip don't throw exceptions on empty sequences?

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); }

I love it! Glad to see this happening. I can't wait for the hard stuff.

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;

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:

## Comments

## C9 Lectures: Dr. Brian Beckman - Covariance and Contravariance in Physics 1 of 1

Brian,

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/

## C9 Lectures: Dr. Brian Beckman - Covariance and Contravariance in Physics 1 of 1

That does help a lot - thank you!

## C9 Lectures: Dr. Brian Beckman - Covariance and Contravariance in Physics 1 of 1

Brian,

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

## C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals Chapter 5 of 13

You seem to be a troll so it's hard to answer in a cooperative spirit. Moving on ...

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.

## C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 3 of 13

Some might like my Haskell Cheatsheet at http://cheatsheet.codeslower.com. It's a short reference & mini-tutorial.

OK - done pimping now

Justin

## C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 2 of 13

Let me pimp my Haskell Cheatsheet, a short syntax reference and minitutorial:

http://cheatsheet.codeslower.com/

## C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 2 of 13

There is Visual Haskell, but it's very out of date. It targest VS 2005, does not use the Managed Package Framework (i.e., it extends VS using C++ rather than .NET), and its married to a really old version of GHC:

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

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

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

Justin

## C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 2 of 13

I would love to see more of this stuff! Please work it in wherever you can.

## C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 2 of 13

I agree regarding obscure code, or anything written in C (** duck **), but of course I don't think that is the case here.

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

## C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 1 of 13

Very nice solution! How does it deal with empty sequences? I assume Take and Skip don't throw exceptions on empty sequences?

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.

## C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 1 of 13

I love it! Glad to see this happening. I can't wait for the hard stuff.

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

## E2E: Erik Meijer and Wes Dyer - Reactive Framework (Rx) Under the Hood 2 of 2

You guys never got to Until (mentioned in part 1). Any follow up details?

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!