Thanks to Greg and Charles for what will surely be another great lecture series.

posted by ryanb

]]>posted by akopacsi

]]>I'm having flashbacks to Brian's clock mon*oid*

The design-by-contract mention is also very interesting.

So far my understanding is that...

methodology Shape = t aka Mr. T wrap = w aka return roll = r aka bind aka SelectMany identity = i integer plus monoid i = w(0) w(0) + w(x) = w(x) w(x) + w(0) = w(x) r(w(a) + w(b)) = r(w(a+b)) = w(a+b) w(0) + w(6) = w(6) w(6) + w(0) = w(6) w(6) + w(1) = w(7) r(w(1) + w(2)) = r(w(1+2)) = r(w(3)) = w(3) am/pm clock monoid aka Beckman Time i = w(0,0) // time is a coordinate-set w(a,b) = w(a%12,b%60) w(a,b) + w(0,0) = w(a,b) w(0,0) + w(a,b) = w(a,b) w(12,0) + w(1,0) = w(1,0) // loss of information r(w(a,b) + w(a',b')) = r(w(a+a',b+b')) = w(a+a',b+b') w(a,0) + w(0,b) = w(a,b) w(0,b) + w(a,0) = w(a,b) w(a,0) + w(b,0) = w(a+b,0) r(w(1,2) + w(4,3)) = r(w(1+4,2+3)) = w(1+4,2+3) = w(5,5) r(w(2,1) + w(3,4)) = r(w(2+3,1+4)) = w(2+3,1+4) = w(5,5) list monoid i = w() w(1) + w() = w(1) w() + w(1) = w(1) w(1) + w(2) = w(1,2) w(2) + w(1) = w(2,1) w(1,2) + w(3,4) = w(1,2,3,4) w(3,4) + w(1,2) = w(3,4,1,2) w(w(1),w(2)) + w(w(3),w(4)) ~ ((1),(2)) + ((3),(4)) = ((1),(2),(3),(4)) r(w(w(1),w(2)) + w(w(3),w(4))) = r(w(w(1),w(2)) + w(w(3),w(4))) = r(w(w(1),w(2),w(3),w(4))) = w(1,2,3,4) // "roll out"

Roll doesn't really make sense for integers and clocks because there's not really any useful structure to flatten, so it becomes a no-op. For sets and lists yes because they can nest. Need to look a little more at the laws - but I love the way you "level" them.

Greg, didn't you mean strings are monads - as conceptually they are just lists of characters and therefore just a particular kind of list.

As Charles would say, if he was trapped in a monad:

"*Wrap 'n Roll!*".

posted by exoteric

]]>When you think about it; where else on the planet can you get educated, for free, by the likes of Erik Meijer, Brian Beckman, Stephan T. Lavavej, Greg Meredith, Yuri Gurevich and Don Syme? We are very fortunate. We'll have more lectures by titans of the industry, too. It's humbling to be a part of this.

Keep on learning. Stretch your minds.

Here's to Future 9.

C

posted by Charles

]]>posted by EFV

]]>I took it that it was meant to be the smallest incremental unit, especially since the unit was 1 and the operator was '+', rather than '*'.

posted by Ken Jackson

]]>A monoid obeys 3 axioms:

**closure**: whenever we compose two integers (+) we get another integer**identity**element: for integer addition (+) this has to be 0; for multiplication 1 ...**associativity**: (a + b) + c = a + (b + c);

for integers this should be true

(1 + 2) + 3 = 1 + (2 + 3);

but actually for lists too!

([1,2] + [3,4]) + [5,6] = [1,2,3,4,5,6] = [1,2] + ([3,4] + [5,6])

So actually lists and by proxy strings (lists of characters) *are indeed* both monoids but as opposed to integers under addition, lists (under append) *are not* commutative.

I guess we could also say that we have an "*integer multiplication monoid*", in that case:

**closure**: multiplying two integers gives another integer --**check****identity**element: 1 since 1 * a = a --**check****associativity**: (a * b) * c = a * (b * c) --**check**

One thing I take away from this (perhaps wrongly) is that just saying "integer monoid" is misleading or ambiguous since there appears to be several ones, depending on what composition operator you choose (+, *, ...)

By the way - Greg is mentioned in the wikipedia article for monads

posted by exoteric

]]>Again, great lecture! I'm looking forward to more!

posted by Novox

]]>posted by exoteric

]]>Timing is a wonderful thing, as I'm starting to get the idea with the help of the below link.

posted by N2Cheval

]]>posted by jand

]]>Thank you Greg for a fantastic introduction to Monads and thanks Charles for making it happen. Great stuff!

I think I finally get a deeper understanding of what a monad is and would like to share an interesting revelation that I had connected with it. I realise what I say may sound somewhat strange but to me:

Monad = LIFE!

Hehe, let me elaborate...well generally speaking monad = change, I like to compare it to a transformation in life, we all go through different stages (wraps) in life and we need means (bind aka roll), in order to get from one stage to another.

It goes quite well with the KISS philosophy as well, the more complicated, scattered our life is, the more unmaintainable it is. What one would like to achieve, is to make his life simpler by taking out the unnecesary fuzz (scattered wraps) out of his life, thus ultimately creating a happier (monadic) version of life for himself, by using a kind of monadic transformation.

In that senese, to me the most difficult part of a monad would be the bind operator then, since this is were the transformation happens. In programming, just as in life, there is not one, universal bind operator, which forces us to come up with customized solutions for both our programs and lives.

Keep the lectures coming, I wonder where the next one will take me;)

posted by dream3n

]]>http://xosfaere.wordpress.com/2010/10/05/shapely-monads/

Thanks for the great brain wash!

PS - looks like Greg's written a book about this:

http://www.amazon.com/Pro-Scala-Monadic-Design-Patterns/dp/143022844X

posted by exoteric

]]>Thanks for posting this!

posted by Justin Bailey

]]>Any news on when the next installment is likely to be available ?

posted by Graham Hay

]]>2 days ago, Graham Hay wrote

Great lecture - very enlightening and worth watching several times over.

Any news on when the next installment is likely to be available ?

Greg is coming to the C9 Studio to film the next part tomorrow, so we'll have it available not too long after that (probably next week sometime).

C

posted by Charles

]]>posted by magicalclick

]]>