monads are fractals


On my way back from Uppsala, my mind wandered to a conversation I had with a collegue about the intuition of monads, which I pretty much butchered at the time. As I was mulling this over, it dawned on me.

Sierpinski triangle

monads are fractals

The above is a fractal called Sierpinski triangle, the only fractal I can remember to draw. Fractals are self-similar structure like the above triangle, in which the parts are similar to the whole (in this case exactly half the scale as parent triangle).

learning Scalaz: nescala 2014


Here are the slide decks and video for learning Scalaz talk:

learning Scalaz: day 21


Added day 21 on html5 book.

learning Scalaz: day 20


Added day 20 on html5 book.

learning Scalaz: day 19


Added day 19 on the html5 book.

Notes on 'Monads Are Not Metaphors'


This is a translation of 「モナドはメタファーではない」に関する補足 by Kenji Yoshida (@xuwei_k), one of the most active Scala bloggers in Japan covering wide range of topics from Play to Scalaz.

Daniel Spiewak's Monads Are Not Metaphors was written about two and a half years ago, but seeing how its Japanese translation is still being tweeted and being bookmarked by 250 users on Hantena, its popularity doesn't seem to cease. I just remembered something to note about the example code used in the post, which could be an unstylish critique, but I'm going to jot it down here. It's an unstylish critique, because I'll be digging into the part where the author likely knew from the beginning but omitted it intentionally for the sake of illustration. Also I'll be using Scalaz in this post.

learning Scalaz, an html5 book


Scalaz 7.0 is out. For easier reading and toc, I converted learning Scalaz series into an html5 book using @n8han's Pamflet:

sudoku using Func


This is the 5th entry of Scalaz Advent Calendar 2012.

During the months of December, tech-savvy geeks in Japan take turns to post themed blog articles, known as the "Advent Calendar". For last year's Scala Advent Calendar 2011 I translated Eric Torreborre's post covering The Essence of Iterator Pattern. It was somewhat of a calculated move, knowing Japanese fondness for functional programming articles. Another selfish motive was that some of the concept would seep in to my thickness as I was translating the post word by word. In hindsight, both goals were achieved handsomely thanks to the quality of both Jeremy Gibbons, Bruno Oliveira and Eric's work. This seeped in knowledge was probably the secret sauce behind the learning Scalaz series that I worked on this year.

As covered in learning Scalaz day 12 Scalaz 7 already included product and compose methods in typeclass instances as well as Traverse. It even has the word count example from the paper. What I realized missing was the value-level composition. One of the interesting points from the paper was "composition of applicative functors," which enables a kind of modular programming.

By "applicative functors" Gibbons and Oliveira actually mean composition of applicative functions, not just the typeclass instances. This is evident in the following snippet from the paper:

data (m ⊠ n) a = Prod { pfst :: m a, psnd :: n a }
() :: (Functor m, Functor n)(a → m b)(a → n b)(a → (m ⊠ n) b)
(f ⊗ g) x = Prod(f x)(gx)

The algebraic data type is the type-level product, while the infix function is the value-level product of two applicative functions, which returns applicative function of type a → (m ⊠ n). In other words, the programmer would construct functions that return an applicative functor, and the type-level compositions are done automatically.

learning Scalaz: day 18


Hey there. There's an updated html5 book version, if you want.

On day 17 we looked at IO monad as a way of abstracting side effects, and Iteratees as a way of handling streams. And the series ended.


I wanted to continue exploring a better way to compose applicative functions, and came up with a wrapper called AppFunc:

val f = AppFuncU { (x: Int) => x + 1 }
val g = AppFuncU { (x: Int) => List(x, 5) }
(f @&&& g) traverse List(1, 2, 3)

learning Scalaz: day 17


Hey there. There's an updated html5 book version, if you want.

Daniel Steger for

Yesterday we looked at Memo for caching computation results, and ST as a way of encapsulating mutation. Today we'll continue into IO.

IO Monad

Instead of reading the second half of the paper, we can get the gist by reading Towards an Effect System in Scala, Part 2: IO Monad by Rúnar (@runarorama):

While ST gives us guarantees that mutable memory is never shared, it says nothing about reading/writing files, throwing exceptions, opening network sockets, database connections, etc.

Syndicate content