Comment Feed for Brian Beckman: Don't fear the Monad (Going Deep on Channel 9)

Re: Brian Beckman: Don't fear the Monads

jhugard — Sun, 29 Jun 2008 02:16:58 GMT

Hey Brian, great chalk-talk! When are you going to take it to the practical with F# work-flows?!?

Re: Brian Beckman: Don't fear the Monads

jdkleban — Sun, 25 May 2008 21:27:30 GMT

Brian writes on the board:

g: a -> Mb
f: b -> Mc
\a -> (g a) >>= \b -> (f b)

but it seems to me that one of two things must be true, either:

The "->" notation means something different in lines 1 and 2 than it does in line 3. In line 1 and 2, "g is a thing (a function) with a type such that it takes a thing of type a and returns a thing of type Mb". In line 3, I don't see how this same interpretation pattern fits over line 3, even with the grouping "\a -> [(g a) >>= \b -> (f b)]".

OR, and more likely because I doubt he wouldn't have noticed:

They do mean the same thing but that there is some even more advanced meaning of the "->" operator, probably something to do with meta-types or kinds or something that applies correctly to each of the lines when understood correctly.

Or, maybe the question is, What is the Bind or Shove operator doing? Is it sheding some metadata surrounding b or c in kinds Mb or Mc and returning the b or c type? Is it de-generalizing a generic Mb or Mc kind??

Sorry, I went to public school but I'm really trying :$.

Maybe listing out how this functional or F# syntax is to be read would help as well. eg. "g: a -> a" is read as "g is a thing, a function, which takes a thing and returns a thing". Even that may be incorrect. Stay as general as possible.

Re: Brian Beckman: Don't fear the Monads

brianbec — Tue, 22 Jan 2008 00:54:23 GMT

orcmid wrote:

brianbec wrote: Here's another little twist ...
Eager evaluation is, in fact, a side effect! Think about it: eager evaluation means that you KNOW function arguments get evaluated BEFORE the function gets called. So, a PURE functional language must be a lazy language (more technically, "non-strict," and sorry for the confusing lingo: STRICT means non-lazy).

BZZT. My non-sequiter detector went off right here, Brian. I think this is over-reaching, as is the later comment about what laziness provides. I'm not completely convinced that the distinction is merely a matter of taste, but I'm also not persuaded that a "pure functional" notion that abandons the well-definedness condition of common mathematics is an appropriate alternative.

Yup, I was wrong about this. When I tried to prove it, I just ended up with the State Monad. I WAS WRONG !!!! :)

Re: Brian Beckman: Don't fear the Monads

orcmid — Wed, 09 Jan 2008 19:30:06 GMT

brianbec wrote:
Here's another little twist ...
Eager evaluation is, in fact, a side effect! Think about it: eager evaluation means that you KNOW function arguments get evaluated BEFORE the function gets called. So, a PURE functional language must be a lazy language (more technically, "non-strict," and sorry for the confusing lingo: STRICT means non-lazy).

BZZT. My non-sequiter detector went off right here, Brian. I think this is over-reaching, as is the later comment about what laziness provides. I'm not completely convinced that the distinction is merely a matter of taste, but I'm also not persuaded that a "pure functional" notion that abandons the well-definedness condition of common mathematics is an appropriate alternative.

Re: Brian Beckman: Don't fear the Monads

kaveh.shahbazian@gmail.com — Fri, 07 Dec 2007 22:55:10 GMT

brianbec wrote:
Very nice, indeed, Kaveh!

Thankyou! I have been more than happy by your comment!
Just I'v discovered a bad thing in my code: using Closures! I discovered this when using a LINQ query against a set of objects (a library for handling directory tree of my html templates for some work and extracting their content and publishing via a HttpHandler). I have changed one of objects that was placed inside the where clause somewhere (in another business class - ofcourse that was a bug; but what if it wasn't?), and the resault was not what expected!
So I write another method for combining two monads and getting a third one; named Transform (I do not know this name is proper. I am a "thin client" of Haskell and Monads!).
It seems now a better solution for composing two (or more monads). It seems to me closures are a bad thing in this context, because they pass the boundries whitout any footprints.
(Code is here.)
Cheers!

Re: Brian Beckman: Don't fear the Monads

augustss — Thu, 06 Dec 2007 12:54:38 GMT

Brian,

I very much agree with your observation that bind is not a very good choice when you want to explain the nature of the monad laws (i.e., the monoidal structure). Instead (as you show), it's the Kleisli composition that makes it obvious.

I wish more people would use your line of explanation since it makes the monad laws look very natural.

BTW, I think strings are a good example of a monoid than everyone has encountered.

-- Lennart

Re: Brian Beckman: Don't fear the Monads

brianbec — Wed, 05 Dec 2007 23:25:46 GMT

Very nice, indeed, Kaveh!

Re: Brian Beckman: Don't fear the Monads

kaveh.shahbazian@gmail.com — Wed, 05 Dec 2007 21:47:07 GMT

I have write a Monad thing in C#. This Monad has a private field that I have not access to, but I can change it! :O And that's the interesting thing about it :P. Once I have pushed a data into it; There is no way out of it. But I can still modify the data in the Monad. Firts let's look at the stuff:

public class Monad<T> : IMonad<T>
{
 private Monad (T inner) { this.__InnerHolder = inner; }
 private Monad () { }

 private readonly T __InnerHolder;
 private T Inner { get { return __InnerHolder; } }
 public static IMonad<TInner> Unit<TInner> (TInner inner)
 { return new Monad<TInner> (inner); }

 public static Func<A, IMonad<R>> Lift<A, R> (Func<A, R> fun)
 {
 if (fun.IsNull ())
 throw new ArgumentNullException
 ("fun", "'fun' can not be null.");
 return (a => Unit<R> (fun (a)));
 }

 public static IMonad Bind<A, B> (IMonad<A> a,
 Func<A, IMonad> fun)
 {
 if (fun.IsNull ()) throw new ArgumentNullException ("fun", "'fun' can not be null.");
 return Unit (fun (a.Monad.Inner).Monad.Inner);
 }

 #region IMonad<T> Members
 Monad<T> IMonad<T>.Monad
 {
 get { return this; }
 }
 #endregion
}

public static partial class MonadExtra
{
 public static IMonad<TInner> Unit<TInner> (this TInner inner)
 { return Monad<object>.Unit<TInner> (inner); }

 public static Func<A, IMonad<R>> Lift<A, R> (this Func<A, R> fun)
 {
 return Monad<object>.Lift<A, R> (fun);
 }

 public static IMonad Bind<A, B> (this IMonad<A> a,
 Func<A, IMonad> fun)
 {
 return Monad<object>.Bind<A, B> (a, fun);
 }
}

public interface IMonad<T>
{
 Monad<T> Monad { get; }
}

Now back to work. First I push a string into my Monad and I want, at the end to have byte collection in my Monad that represents the charachters of my string. How about this:

var var1 = "ABCD...MONAD!"
 .Unit ()
 .Bind ((string s) => s.ToCharArray ().Unit ())
 .Bind (ca => (from c in ca select Convert.ToByte (c)).Unit ());

What is the type of var1? It is IMonad<IEnumerable<byte>>. And you see another interesting aspects of Monad here: Composability! Here we have 3 type for the type variable of our Monad. But as long as we are IN the Monad we can compose any kind of computations.

Now assume we have two Monads and we want to apply a function to the inner value of both monads. How can I pull out the values from these Monads to perform my function application? I can not pull out the inner part of monads. But i can still use their values in my computation by using closures! For example I have to Monads that contains numbers and I want to have the multipluy value of them:

var ma = 10.Unit ();
var mb = 20.Unit ();

var mr = mb
.Bind (x => ma.Bind (y => (x * y).ToString ().Unit ()));

As you can see (actually as I can see! Because writing this code make me feel a lot better about Monads - as an Imperative programmer - yet there are a lot of improvements possible to my Monad set of utilities) anything that we do in normal imperative code is possible by using this Monad. What is the good part? You can not change the Monad anywhere out of the Monad. So actually the state of you whole program that is out of the Monad is untouched. Another thing is that the Monad is immutable. Every action on a Monad produce a new Monad of that kind.
Consider a data structure that has Monads as members. You can not modify these members! Even if the data structure itself is not a Monad! See this little bit of it:

var nv = new { a = 10.Unit (), b = 20.Unit () };
var mnv = nv.Unit ();
mnv = mnv
   .Bind (j => new {
            a = j.a.Bind (k => (k * 2).Unit ()),
            b = j.b.Bind (k => (k * 2).Unit ()) }.Unit ());

It was very interesting to me that by putting a Monad of this type as a member of the root class of a hierarchy; that hierarchi of classes became immutable! (At least for changing that member!)

Re: Brian Beckman: Don't fear the Monads

brianbec — Wed, 05 Dec 2007 19:06:06 GMT

akopacsi wrote:
Hello Guys,

Great video! It's always great to see Brian.

(Brianbec fans! Do not miss Brian's interview at
http://channel8.msdn.com/Posts/Brian-Beckman-I-have-an-idea-then-what
:-)

May I ask a question? How many real-world applications are there that are based on functional programming? I heard somewhere that functional principles appear in Google Maps and Google Earth. I'm not sure if it's true or not... I just mentioned. It'd be nice to learn more about some real examples.

Since you mentioned Google, map-reduce, which is the backbone of their massively distributed, parallel infrastructure, is a composition of "reduce", which applies some given aggregate, associative calculation like sum or average or standard-deviation to a recursive data structure; with "map", which applies arbitrary transformations to a recursive data structure. It's about as functional and real-world as it gets.

There are tons of other examples. Some in the financial quants industry are using Haskell programs to model derivatives yields. I know the crypto community is going whole-hog for Haskell. Don's blog (http://blogs.msdn.com/dsyme/ ) will be a great place to look at real-world applications of F#. Erlang is all over the communications industry. It's endless :)

EDIT: I wanted to add a side comment: one reason some mission-critical applications are going with Haskell is that if you go "all the way" to pure functional programming, where all side-effects are accounted for in type signatures, then more proofs of correctness become available. In certain cases, this is required.

But, on the downside, you can't just plunk down a "print" statement any-old-where to help you debug a Haskell program. Any computation that might EVER print MUST be in the IO monad. So if you're ever going to plunk down a print, you must plan ahead for it or rewrite for it. In the "impure" world of .NET, with C#3.0, VB9, and F#, you have many of the benefits of functional style, but you can "cheat" where necessary or useful and do side effects from anywhere.

Re: Brian Beckman: Don't fear the Monads

brianbec — Wed, 05 Dec 2007 07:29:33 GMT

dottedmag wrote:
Thanks for great video, it has been best introduction to monads I've seen so far! Most of the "monad tutorials" really suck and they all forget about the outer lambda in composition :) Composability is explained perfectly, however composability could be achieved by just having a proper type signatures! Imagine you have semigroup: set of objects and associative operation. You don't have identity, but you still closed against composition. So it is not clear what's the purpose of "monadic rules" - why associativity and identity are required? What changes if (>>=) is not associative? What can't be achieved when there is no 'return'? I hope it will be a good be a good theme for a next lecture.

These are great questions. The identity is in there so we can "lift" values into the computation (that is, the monad) without changing them. No return, no general way to get into the monad in the first place.

Associativity makes monads good for modeling ordered collections like lists. It would be terrible if [a] ++ ([z] ++ [c]) weren't guaranteed to be the same as ([a] ++ [z]) ++ [c]. Imagining a ++ operator that eats its left-hand side if it's out of lexicographic order, then

[a] ++ ([z] ++ [c]) = [a] ++ [c] = [a, c]
([a] ++ [z]) ++ [c] = [a, z] ++ [c] = [a, z, c]

This bogus ++ is not monadic because it's not associative, and it's a good thing to exclude it from our general (but not too general) discipline.

There is probably a deeper reason (hello, categorists :), but this is what popped to mind.

Re: Brian Beckman: Don't fear the Monads

mixelz — Sun, 02 Dec 2007 22:00:00 GMT

A good paper about monads is actually by Simon Peyton Jones from Microsoft:
http://research.microsoft.com/Users/simonpj/papers/marktoberdorf/
You have to have some Haskell knowledge though..

Re: Brian Beckman: Don't fear the Monads

akopacsi — Sun, 02 Dec 2007 19:19:31 GMT

Hello Guys,

Great video! It's always great to see Brian.

(Brianbec fans! Do not miss Brian's interview at
http://channel8.msdn.com/Posts/Brian-Beckman-I-have-an-idea-then-what
:-)

May I ask a question? How many real-world applications are there that are based on functional programming? I heard somewhere that functional principles appear in Google Maps and Google Earth. I'm not sure if it's true or not... I just mentioned. It'd be nice to learn more about some real examples.

Re: Brian Beckman: Don't fear the Monads

dottedmag — Sat, 01 Dec 2007 21:13:41 GMT

Thanks for great video, it has been best introduction to monads I've seen so far! Most of the "monad tutorials" really suck and they all forget about the outer lambda in composition :) Composability is explained perfectly, however composability could be achieved by just having a proper type signatures! Imagine you have semigroup: set of objects and associative operation. You don't have identity, but you still closed against composition. So it is not clear what's the purpose of "monadic rules" - why associativity and identity are required? What changes if (>>=) is not associative? What can't be achieved when there is no 'return'? I hope it will be a good be a good theme for a next lecture.

Re: Brian Beckman: Don't fear the Monads

brianbec — Wed, 28 Nov 2007 16:14:13 GMT

Beta wrote:

Hi guys,

Both Brian's F# interview and Joe Armstrong's Erlang interview(from JAOO) have got me really interested in functional programming.

So I'm looking to get started with functional programming and Erlang and F# have both sparked my interest equally ... So; I'm kind of stuck on which one to study?

Has anyone got any decent pro/con lists for me to take into consideration? As, unfortunately (or, most probably, fortunately) the web isn't littered with Erlang Vs. F# wars, the way it is with C# Vs VB.NET, Java Vs. C++, etc,etc, for me to browse.

Cheers

To get into full, pure functional programming: the only game in town is Haskell (www.haskell.org :) The web site is loaded with tutorials and samples and other beautiful stuff. If you have the time to dig in and learn, it will be intellectually transforming and rejuvenating. But there's no bridging the chasm back even to the partly-functional world of .NET (getting into Haskell is like getting into a Monad -- you can't get out [pun intended]).

C# 3.0, VB 9, and F# all three now have first-class functions (lambda expressions), so you can experience many of the benefits of functional programming in any of those three, and F# has a syntax and a "look and feel" closer to Haskell, especially for purely sequential programs. If you've done any Scheme programming, then you will breathe a sigh of happiness with any of these three languages, now with LINQ and lambda. I don't have any experience with Erlang, so I can't chime in there.

Re: Brian Beckman: Don't fear the Monads

Beta — Tue, 27 Nov 2007 20:51:05 GMT

Hi guys,

Both Brian's F# interview and Joe Armstrong's Erlang interview(from JAOO) have got me really interested in functional programming.

So I'm looking to get started with functional programming and Erlang and F# have both sparked my interest equally ... So; I'm kind of stuck on which one to study?

Has anyone got any decent pro/con lists for me to take into consideration? As, unfortunately (or, most probably, fortunately) the web isn't littered with Erlang Vs. F# wars, the way it is with C# Vs VB.NET, Java Vs. C++, etc,etc, for me to browse.

Cheers :)

Re: Combining C# And F#

brianbec — Tue, 27 Nov 2007 04:34:28 GMT

esoteric wrote:
A possible supplement to Brian's excellent introduction to Monads.

The n-Category Café

featuring YouTube videos.

Superb!!!

Re: Brian Beckman: Don't fear the Monads

bobbyorr — Mon, 26 Nov 2007 21:50:11 GMT

"All nouny, no verby"

Cool!

Re: Combining C# And F#

Bent Rasmussen — Mon, 26 Nov 2007 20:36:24 GMT

A possible supplement to Brian's excellent introduction to Monads.

The n-Category Café

featuring YouTube videos.

Re: Combining C# And F#

Charles — Mon, 26 Nov 2007 20:33:06 GMT

Apogeum wrote:
Thats great!

I am really looking forward to seeing more great interviews like this one.

You can bet on it. Next up will be a deep dive into pure functional programming (and why, at least from the interviewee's point of view, it's the only way to go) with another expert in the domain and great personality.

Stay tuned.
C

Combining C# And F#

Apogeum — Mon, 26 Nov 2007 20:26:24 GMT

Thats great!

I still don't think I understand monads and functional programming, my lack of math background is complicating things. But I totally get the complexity built on simplicity to ensure composability part, that is kind of my whole bid.

simplicity meaning: "easy to decide" as opposed to "easy, because I don't have to decide". so I guess functional programming will still require a very particular mindset to be successfully employed.

I am really looking forward to seeing more great interviews like this one.

Re: Brian Beckman: Don't fear the Monad

brianbec — Mon, 26 Nov 2007 17:39:19 GMT

Here are a couple of great, motivational papers on functional programming in general and Haskell in particular

"Why Functional Programming Matters,"

http://www.md.chalmers.se/~rjmh/Papers/whyfp.html

"Why Haskell Matters,"

http://www.haskell.org/haskellwiki/Why_Haskell_Matters

Re: Brian Beckman: Don't fear the Monad

brianbec — Mon, 26 Nov 2007 16:01:52 GMT

esoteric wrote:
Also - is monads really "the" way to structure libraries?

I would say that "composability" or "compositionality" is THE way to structure libraries. Monads aren't the ONLY way to build-in compositionality from the outset in a design, but they're a very common pattern, broadly applicable, fully understood.

Re: Brian Beckman: Don't fear the Monad

brianbec — Mon, 26 Nov 2007 15:58:48 GMT

Apogeum wrote:
is it possible to mix c# and f#? (I'm new to this, obviously)

Yes, since both C# and F# are full "citizens" of .NET, you can call methods in one from the other and back very easily.

Re: Brian Beckman: Don't fear the Monads

William Stacey — Mon, 26 Nov 2007 15:45:03 GMT

Great. However still confused about real world and how this removes issues with shared state and locking. So, for example, I have 1 Customer object (Name and OrderCount) that is shared today in my program. Say I have a shared static ref to it and threads in my program take a lock before reading or writing any properties on this object. So how does this look with functional programming. I assume it involves making ctor copies, but don't see the light yet. Small example would help. tia

Re: Brian Beckman: Don't fear the Monad

Bent Rasmussen — Mon, 26 Nov 2007 15:44:06 GMT

I understand monads better now. Once I understand them "fully", perhaps it's time to move onto: arrows? http://www.haskell.org/arrows/. Also - is monads really "the" way to structure libraries?