# Monoids are not demode and thursdays are actually the new fridays

No, it’s not the latest Coixet’s movie title. When we talk about cathegories like monoids, we tend to think they just remain on the edge as something merely experimental (even though purely functional) and there’s no direct application at the real world. Something similar happened when you learnt square roots at school and there was no proper moment to start using them at real life… ## The use case

This morning, ah naïve me, I tried to make this work:

```type Passengers = Int
type MaxCapacity = Passengers
type Plane = (Passengers, MaxCapacity)

val planes: List[Plane] =
List(1 -> 1, 2 -> 3, 3 -> 3)

val (totalPassengers, totalCapacity) =
planes.sum
//  ERROR: Could not find implicit value
//  for parameter num: Numeric[(Int, Int)]
```

Ok, fair enough, Scala needs something, an evidence, for adding integer tuples.
Before we start fighting with the ‘evidence’, let’s try to make it work in a more mechanical way:

```val sum = ((0,0) /: planes){
case ((totalPas,totalCap), (passengers, capacity)) =>
(totalPas + passengers, totalCap + capacity)
}
```

Okay, it works. But it should be simpler, so let’s get back to the idea of `Numeric[N]` evidence.

## Implementing `Numeric[N]`

We need a `Numeric[(A,B)]` but before implementing it (it has a lot of abstract methods) let’s sweep under the rug all those methods we don’t really want to focus on in this example. For doing so, let’s create an intermediate layer that keeps all those method without an implementation (which doesn’t mean ‘abstract’):

```trait LeanNumeric[T] extends Numeric[T] {
override def fromInt(x: Int): T = ???
override def toInt(x: T): Int = ???
override def minus(x: T, y: T): T = ???
override def times(x: T, y: T): T = ???
override def negate(x: T): T = ???
override def toLong(x: T): Long = ???
override def toFloat(x: T): Float = ???
override def toDouble(x: T): Double = ???
override def compare(x: T, y: T): Int = ???
}
```

Let’s call this abomination LeanNumeric (it only contains the essentials to develop our example). And now, we can define the method that generates the evidence for any `Tuple2`:

```implicit def numeric[A, B](
implicit nA: Numeric[A],
nB: Numeric[B]): Numeric[(A, B)] = {
new LeanNumeric[(A, B)]{
override def zero = (nA.zero, nB.zero)
override def plus(x: (A, B), y: (A, B)): (A, B) = {
val (a1, b1) = x
val (a2, b2) = y
(nA.plus(a1, a2), nB.plus(b1, b2))
}
}
}
```

If we put the implicit into scope and we run again `planes.sum`…boom! Magic.

## Num…oid

We don’t have to master category theory to realize that `Numeric[N]` may be a thousand of things, but it satisfies at least two properties:

Seriously? Isn’t it obvious enough? My dear friends, monoid is back in town!

## Implementation with `scalaz.Monoid`

Having in mind that Numeric has (at least) these two properties, let’s re-implement the implicit by using scalaz Monoid. We first define the monoid for integers and the tuple monoid which requires a monoid for each type that compounds the tuple (easy peasy):

```import scalaz._

implicit object IntMonoid extends Monoid[Int]{
override def zero: Int = 0
override def append(f1: Int, f2: => Int): Int = f1 + f2
}

implicit def tupleMonoid[A,B](
implicit mA: Monoid[A],
mB: Monoid[B]): Monoid[(A,B)] = {
new Monoid[(A, B)] {
override def zero: (A, B) = (mA.zero, mB.zero)
override def append(f1: (A, B), f2: => (A, B)): (A, B) = {
val (a1, b1) = f1
lazy val (a2, b2) = f2
(mA.append(a1,a2), mB.append(b1, b2))
}
}
}
```

So good so far, right? After that, we implement the implicit that will provide a Numeric as long as there’s a Monoid for the type

```implicit def numeric[T](
implicit m: Monoid[T]): Numeric[T] = {
new LeanNumeric[T]{
override def zero = m.zero
override def plus(x: T, y: T): T = m.append(x, y)
}
}

planes.sum //(6,7)
```

And it’s awesomely easy to get abstract of whatever T means (a tuple? a dog? …). As long as it’s a monoid, you can define a LeanNumeric.

You can find here the gist.

See you in the next functional madness.

Peace out!

# Los monoides no están demodé y los jueves sí son los nuevos viernes

No, no es el título de la nueva película de Coixet. Cuando hablamos de categorías como los monoides, tendemos a pensar que se quedan en el ámbito de lo experimental (aunque funcionalmente puro) y que no existe aplicación directa sobre el mundo real. Algo parecido a lo que ocurría cuando te enseñaban a hacer raíces cuadradas en el colegio y no veías el momento para usarlo en la vida real… ## El caso de uso

Esta misma mañana, ingenuo de mi, intentaba hacer que funcionara lo siguiente:

```type Passengers = Int
type MaxCapacity = Passengers
type Plane = (Passengers, MaxCapacity)

val planes: List[Plane] =
List(1 -> 1, 2 -> 3, 3 -> 3)

val (totalPassengers, totalCapacity) =
planes.sum
//  ERROR: Could not find implicit value
//  for parameter num: Numeric[(Int, Int)]
```

Vale, comprensible, Scala necesita algo, una evidencia, para poder sumar tuplas de enteros.
Antes de pegarnos con la “evidencia”, intentemos hacerlo funcionar de una manera mucho más mecánica:

```val sum = ((0,0) /: planes){
case ((totalPas,totalCap), (passengers, capacity)) =>
(totalPas + passengers, totalCap + capacity)
}
```

Okay, funciona. Pero debería ser algo más simple, por lo que retomemos la idea de la evidencia `Numeric[N]`.

## Implementando `Numeric[N]`

Necesitamos un `Numeric[(A,B)]` pero antes de implementarlo (tiene bastantes métodos abstractos) escondamos debajo de la alfombra aquellos métodos en los cuales no queremos centrarnos en este ejemplo. Para ello creamos una capa por encima que deje los métodos sin implementar (que no abstractos):

```trait LeanNumeric[T] extends Numeric[T] {
override def fromInt(x: Int): T = ???
override def toInt(x: T): Int = ???
override def minus(x: T, y: T): T = ???
override def times(x: T, y: T): T = ???
override def negate(x: T): T = ???
override def toLong(x: T): Long = ???
override def toFloat(x: T): Float = ???
override def toDouble(x: T): Double = ???
override def compare(x: T, y: T): Int = ???
}
```

A esta aberración la llamaremos LeanNumeric (solo contiene lo esencial para desarrollar nuestro ejemplo). Y ahora definimos el método que genera la evidencia para cualquier `Tuple2`:

```implicit def numeric[A, B](
implicit nA: Numeric[A],
nB: Numeric[B]): Numeric[(A, B)] = {
new LeanNumeric[(A, B)]{
override def zero = (nA.zero, nB.zero)
override def plus(x: (A, B), y: (A, B)): (A, B) = {
val (a1, b1) = x
val (a2, b2) = y
(nA.plus(a1, a2), nB.plus(b1, b2))
}
}
}
```

Si ponemos el implícito en scope y ejecutamos de nuevo el `planes.sum`…¡boom! Magia.

## Num…oide

No hace falta saber mucho de teoría de categorías para centrarse en que `Numeric[N]`, podrá ser mil cosas más, pero cumple dos propiedades:

¿en serio?¿No es evidente?…amigos, ¡el monoide ha vuelto a la ciudad!

## Implementación con `scalaz.Monoid`

Viendo que el tipo Numeric tiene al menos esas dos propiedades, re-implementamos el implícito haciendo uso de Monoid. Primero definimos el monoide para enteros y el monoide de las tuplas,
el cual requiere de un monoide para cada tipo que compone la tupla (easy peasy)

```import scalaz._

implicit object IntMonoid extends Monoid[Int]{
override def zero: Int = 0
override def append(f1: Int, f2: => Int): Int = f1 + f2
}

implicit def tupleMonoid[A,B](
implicit mA: Monoid[A],
mB: Monoid[B]): Monoid[(A,B)] = {
new Monoid[(A, B)] {
override def zero: (A, B) = (mA.zero, mB.zero)
override def append(f1: (A, B), f2: => (A, B)): (A, B) = {
val (a1, b1) = f1
lazy val (a2, b2) = f2
(mA.append(a1,a2), mB.append(b1, b2))
}
}
}
```

Hasta aquí bien, ¿correcto? Implementemos ahora el implícito que nos proporcionará un Numeric siempre que exista un Monoid para el tipo

```implicit def numeric[T](
implicit m: Monoid[T]): Numeric[T] = {
new LeanNumeric[T]{
override def zero = m.zero
override def plus(x: T, y: T): T = m.append(x, y)
}
}

planes.sum //(6,7)
```

Y es increiblemente sencillo abstraerse de lo que demonios sea T (¿una tupla?, ¿un perro?, …).
Mientras sea un monoide, se puede definir un LeanNumeric.

Podéis encontrar aquí el gist resumen

Hasta la próxima locura funcional.

¡Agur de limón!

# More lazy values, the State monad and other stateful stuff

In the previous post, we talked about lazy evaluation in Scala. At the end of that post, we asked an interesting question: Does a `Lazy` value hold an state? In order to answer that question, we’ll try to define a type that could represent the Lazy values:

```trait Lazy[T] {

val evalF : () => T

val value: Option[T] = None

}
object Lazy{
def apply[T](f: => T): Lazy[T] =
new Lazy[T]{ val evalF = () => f }
}
```

As you can see, our `Lazy` type is parameterized by some `T` type that represents the actual value type(`Lazy[Int]` would be the representation for a lazy integer).
Besides that, we can see that it’s composed of the two main Lazy type features:

• evalF : Zero-parameter function that, when its ‘apply’ method is invoked, it evaluates the contained T expression.
• value : The result value of the interpretation of the `evalF` function. This concrete part denotes the state in the `Lazy` type, and it only admit two possible values: `None` (not evaluated) or `Some(t)` (if it has been already evaluated and the result itself).

We’ve also added a companion object that defines the Lazy instance constructor that receives a by-name parameter that is returned as result of the `evalF` function. Now the question is, how do we join both the evaluation function and the value that it returns so we can make `Lazy` an stateful type? We define the ‘eval’ function this way:

```trait Lazy[T] { lzy =>

val evalF : () => T

val value: Option[T] = None

def eval: (T, Lazy[T]) = {
val evaluated = evalF.apply()
evaluated -> new Lazy[T]{ mutated =>
val evalF = lzy.evalF
override val value = Some(evaluated)
override def eval: (T, Lazy[T]) =
evaluated -> mutated
}
}

}
```

The ‘eval’ function returns a two-element tuple:

• The value result of evaluating the expression that stands for the lazy value.
• a new `Lazy` value version that contains the new state: the T evaluation result.

If you take a closer look, what ‘eval’ method does in first place is to invoke the evalF function so it can retrieved the T value that remained until that point not-evaluated.
Once done, we return it as well as the new Lazy value version. This new version (let’s call it `mutated` version) will have in its ‘value’ attribute the result of having invoked the `evalF` function. In the same way, we change its `eval` method, so in future invocations the Lazy instance itself is returned instead of creating new instances (because it actually won’t change its state, like Scala’s lazy definitions work).

The interesting question that comes next is: is this an isolated case? Could anything else be defined as stateful? Let’s perform an abstraction exercise.

## Looking for generics: stateful stuff

Let’s think about a simple stack:

```sealed trait Stack[+T]
case object Empty extends Stack[Nothing]
case class NonEmpty[T](head: T, tail: Stack[T]) extends Stack
```

The implementation is really simple. But let’s focus in the `Stack` trait and in a hypothetical `pop` method that pops an element from the stack so it is returned as well as the rest of the stack:

```sealed trait Stack[+T]{
def pop(): (Option[T], Stack[T])
}
```

Does it sound familiar to you? It is mysteriously similar to

```trait Lazy[T]{
def eval: (T, Lazy[T])
}
```

isn’t it?

If we try to re-factor for getting a common trait between `Lazy` and `Stack`, we could define a much more abstract type called `State`:

```trait State[S,T] {
def apply(s: S): (T, S)
}
```

Simple but pretty: the `State` trait is parameterized by two types: S (state type) and T (info or additional element that is returned in the specified state mutation). Though it’s simple, it’s also a ver common pattern when designing Scala systems. There’s always something that holds certain state. And everything that has an state, it mutates. And if something mutates in a fancy and smart way…oh man.

## That already exists… All this story that seems to be created from a post-modern essay, has already been subject of study for people…that study stuff. Without going into greater detail, in ScalaZ library you can find the `State` monad that, apart from what was previously pointed, is fully-equipped with composability and everything that being a monad means (semigroup, monoid, …).

If we define our Lazy type with the State monad, we’ll get something similar to:

```import scalaz.State

type Lazy[T] = (() => T, Option[T])

def Lazy[T](f: => T) = (() => f, None)

def eval[T] = State[Lazy[T], T]{
case ((f, None)) => {
val evaluated = f.apply()
((f, Some(evaluated)), evaluated)
}
case s@((_, Some(evaluated))) => (s, evaluated)
}
```

When decrypting the egyptian hieroglyph, given the `State[S,T]` monad, we have that our S state will be a tuple composed of what exactly represents a lazy expression (that we also previously described):

```type Lazy[T] = (() => T, Option[T])
```
• A Function0 that represents the lazy evaluation of T
• The T value that might have been evaluated or not

For building a Lazy value, we generate a tuple with a function that stands for the expression pointed with the by-name parameter of the `Lazy` method; and the None value (because the Lazy guy hasn’t been evaluated yet):

```def Lazy[T](f: => T) = (() => f, None)
```

Last, but not least (it’s actually the most important part), we define the only state transition that is possible in this type: the evaluation. This is the key when designing any State type builder: how to model what out S type stands for and the possible state transitions that we might consider.

In the case of the Lazy type, we have two possible situations: the expression hasn’t been evaluated yet (in that case, we’ll evaluate it and we’ll return the same function and the result) or the expression has been already evaluated (in that case we won’t change the state at all and we’ll return the evaluation result):

```def eval[T] = State[Lazy[T], T]{
case ((f, None)) => {
val evaluated = f.apply()
((f, Some(evaluated)), evaluated)
}
case s@((_, Some(evaluated))) => (s, evaluated)
}
``` In order to check that we can still count on the initial features we described for the Lazy type (it can only be evaluated once, only when necessary, …) we check the following assertions:

```var sideEffectDetector: Int = 0

val two = Lazy {
sideEffectDetector += 1
2
}

require(sideEffectDetector==0)

val (_, (evaluated, evaluated2)) = (for {
evaluated <- eval[Int]
evaluated2 <- eval[Int]
} yield (evaluated, evaluated2)).apply(two)

require(sideEffectDetector == 1)
require(evaluated == 2)
require(evaluated2 == 2)
```

Please, do notice that, as we mentioned before, what is defined inside the for-comprehension are the same transitions or steps that the state we decide will face. That means that we define the mutations that any S state will suffer. Once the recipe is defined, we apply it to the initial state we want.
In this particular case, we define as initial state a lazy integer that will hold the 2 value. For checking the amount of times that our Lazy guy is evaluated, we just add a very dummy var that will be used as a counter. After that, we define inside our recipe that the state must mutate twice by ussing the `eval` operation. Afterwards we’ll check that the expression of the Lazy block has only been evaluated once and that the returning value is the expected one.

I wish you the best tea for digesting all this crazy story 🙂
Please, feel free to add comments/menaces at the end of this post or even at our gitter channel.

See you on next post.
Peace out!

# Más lazy’s, la mónada State y otras cosas con estado

En el anterior post hablábamos sobre la evaluación perezosa en Scala. Al final de dicho post, planteábamos una pregunta: ¿Un `Lazy` tiene estado? Para responder a dicha pregunta, vamos a intentar definir un tipo que represente un valor Lazy como sigue:

```trait Lazy[T] {

val evalF : () => T

val value: Option[T] = None

}
object Lazy{
def apply[T](f: => T): Lazy[T] =
new Lazy[T]{ val evalF = () => f }
}
```

Como se puede observar, nuestro tipo `Lazy` está parametrizado por un tipo `T` que representa el tipo del valor en cuestión(`Lazy[Int]` sería la representación de un entero perezoso).
Además, podemos ver que se compone de dos elementos principales que caracterizan a un Lazy:

• evalF : Función de cero argumentos que, al invocar su método apply, evalúa la expresión de T contenida.
• value : El valor resultante de la interpretación de la función `evalF`. Esta parte es la que denota el estado en el tipo `Lazy`, y solo admite dos posibles valores: `None` (no evaluado) o `Some(t)` (si ya ha sido evaluado y el resultado obtenido).

También hemos añadido un objeto companion que define el constructor de instancias Lazy que recibe un argumento by-name que se devuelve como resultado de la función `evalF`. La cuestión ahora es: ¿Cómo unimos la función de evaluación con el valor que devuelve para hacer que `Lazy` mantenga un estado? Definiendo la función eval:

```trait Lazy[T] { lzy =>

val evalF : () => T

val value: Option[T] = None

def eval: (T, Lazy[T]) = {
val evaluated = evalF.apply()
evaluated -> new Lazy[T]{ mutated =>
val evalF = lzy.evalF
override val value = Some(evaluated)
override def eval: (T, Lazy[T]) =
evaluated -> mutated
}
}

}
```

La función eval devuelve una tupla de dos elementos:

• el valor resultante de la evaluación de la expresión que representa el valor perezoso.
• una nueva versión del valor `Lazy` que contiene el nuevo estado: el resultado de la evaluación.

Si os fijáis, lo que hace el método en primer lugar, es invocar a la función evalF para obtener el valor de tipo T que aún estaba sin evaluar.
Una vez hecho esto, lo devolvemos así como la nueva versión del elemento Lazy. Esta nueva versión (llamémosla `mutated`) tendrá en su atributo value el resultado de haber invocado a `evalF`. Del mismo modo, modificamos su método `eval`, para que en sucesivas invocaciones se devuelva a sí mismo y no genere nueva instancias que en realidad no varían su estado.

La cuestión interesante viene ahora: ¿es este un caso único? ¿Existen más ‘cosas’ que mantienen un estado? Hagamos un ejercicio de abstracción.

## Buscando la genericidad: cosas-con-estado

Pensemos en el caso de una pila:

```sealed trait Stack[+T]
case object Empty extends Stack[Nothing]
case class NonEmpty[T](head: T, tail: Stack[T]) extends Stack
```

La implementación sale casi sola. Pero centrémonos en el trait `Stack` y en un hipotético método `pop` que desapila un elemento que se devuelve junto al resto de la pila:

```sealed trait Stack[+T]{
def pop(): (Option[T], Stack[T])
}
```

¿Os suena de algo? ¿No se parece misteriosamente a

```trait Lazy[T]{
def eval: (T, Lazy[T])
}
```

…?

Si intentamos sacar factor común entre `Lazy` y `Stack` podríamos definir un tipo mucho más abstracto llamado `State`:

```trait State[S,T] {
def apply(s: S): (T, S)
}
```

Simple pero bello: el trait `State` está parametrizado por dos tipos: S (tipo de estado) y T (información o elemento adicional que devuelve cada vez que mutamos el estado). Aquí donde lo veis, se trata de un patrón muy recurrente al diseñar sistemas en Scala. Siempre hay algo que mantiene un estado. Y todo lo que tiene estado muta. Y si ese algo muta de manera segura y elegante…oh man.

## Esto ya existe … Toda esta historia que parece sacada de un ensayo post-moderno, resulta que ya ha sido objeto de estudio de personas que estudian cosas. Sin entrar en mucho detalle, en la librería ScalaZ podéis encontrar la mónada `State` que, además de lo descrito anteriormente, trae de serie un full-equipped de componibilidad y todo lo que conlleva ser Mónada (semigrupo, monoide, etc).

Si definimos nuestro tipo Lazy con la mónada State tenemos algo como:

```import scalaz.State

type Lazy[T] = (() => T, Option[T])

def Lazy[T](f: => T) = (() => f, None)

def eval[T] = State[Lazy[T], T]{
case ((f, None)) => {
val evaluated = f.apply()
((f, Some(evaluated)), evaluated)
}
case s@((_, Some(evaluated))) => (s, evaluated)
}
```

Al descomponer el jeroglífico egipcio arriba expuesto, dada la mónada `State[S,T]`, nuestro estado S va a ser una tupla de lo que representa en el fondo a una evaluación perezosa:

```type Lazy[T] = (() => T, Option[T])
```

y que más arriba hemos descrito:

• Una Function0 que representa la evaluación demorada de T
• El valor T que puede haberse evaluado o no

Para construir un valor Lazy, generamos una tupla con una función que recoge la expresión indicada por un argumento by-name del método `Lazy` y el valor None (porque aún no ha sido evaluado el Lazy):

```def Lazy[T](f: => T) = (() => f, None)
```

Por último (y esta es la parte importante) definimos la única transición posible de estado que podemos concebir cuando hablamos de valores perezosos: la evaluación. Esta es la clave cuando diseñamos cualquier constructor de tipos que extiende de State: lo importante es modelar qué es nuestro tipo S y las transiciones de estado posibles.

Para el tipo Lazy, tenemos dos posibles casos: que la expresión aún no haya sido evaluada (en cuyo caso la evaluamos y devolvemos la misma función y el resultado) ó que la expresión ya haya sido evaluada (en cuyo caso dejamos el estado como está y devolvemos además el resultado de la evaluación):

```def eval[T] = State[Lazy[T], T]{
case ((f, None)) => {
val evaluated = f.apply()
((f, Some(evaluated)), evaluated)
}
case s@((_, Some(evaluated))) => (s, evaluated)
}
``` Para comprobar que seguimos contando con las mismas características iniciales para las que definimos el tipo Lazy (solo se evalúa una vez, solo se evalúa cuando es necesario, …) lanzamos las siguiente aserciones:

```var sideEffectDetector: Int = 0

val two = Lazy {
sideEffectDetector += 1
2
}

require(sideEffectDetector==0)

val (_, (evaluated, evaluated2)) = (for {
evaluated <- eval[Int]
evaluated2 <- eval[Int]
} yield (evaluated, evaluated2)).apply(two)

require(sideEffectDetector == 1)
require(evaluated == 2)
require(evaluated2 == 2)
```

Si os fijáis, como antes comentábamos, lo que se define en la for-comprehension son las transiciones o pasos que va a enfrentar el estado que nosotros queramos. Es decir, definimos las mutaciones que sufrirá un estado S cualquiera. Una vez definida la ‘receta’, la aplicamos al estado inicial que nosotros queramos.
En este caso, definimos como estado inicial un perezoso número entero dos. Para comprobar el número de veces que se evalúa nuestro Lazy, añadimos un var muy dummy que funcionará a modo de contador. Luego definimos en nuestra ‘receta’ que el estado debe mutar dos veces mediante la operación `eval`. Posteriormente comprobamos que solo se ha ejecutado una vez la expresión del bloque Lazy y que el valor resultante de la expresión es el esperado.

Os deseo la mejor de las sales de frutas para digerir todo esto 🙂
Sentíos libres de añadir comentarios/amenazas en el post o en nuestro canal de gitter.

Hasta el próximo post.
¡Agur de limón!

# Teoría de Cate-movidas: Monoides

Somos como las colecciones de soldaditos de plomo y las matrículas gratis en los gimnasios… ¡volvemos en Septiembre!
Y volvemos con algo que parece muy heavy pero que seguro que después de leer unas pocas líneas será más sencillo.
Hoy comenzamos con una serie de post en las que hablaremos de algunas abstracciones funcionales, muy relacionadas con el mundo de las matemáticas, con el objetivo de introducirnos poco a poco en el mundo de las librerías puramente funcionales de Scala, como pueden ser Scalaz y Cats. Para ello, vamos a apoyarnos en algunas características y técnicas que ya hemos tratado anteriormente, como por ejemplo, las type classes.

Por ello, hoy vamos a comenzar con los monoides.

Monoides, monoides everywhere…

¿Monoide? Un palabro un poco raro. Vamos a ver que dice Wikipedia sobre los monoides:

“Estructura algebraica con una operación binaria, que es asociativa y tiene elemento neutro, es decir, es un semigrupo con elemento neutro.” Ah…si, claro. Ya lo pillo…… Vamos a analizarlo poco a poco.

• Operación binaria: ok, eso lo entiendo. Es una operación con dos operandos. Para tener un convenio, llamaremos a esta operación de forma genérica con el símbolo |+|

Sin embargo, la operación binaria tiene que cumplir dos reglas:

1. Debe cumplir la propiedad asociativa, es decir:  a |+| (b + c) = (a + b) |+| c
2. Y además, debe tener un elemento neutro:   a |+| elementoNeutro = a

Mmmm, ya está más claro. Entonces, la suma de enteros cumple las reglas de los monoides:

• Cumple la propiedad asociativa: 1 + (2 + 3) = (1+ 2) + 3
• Tiene un elemento neutro, el cero: 1 + 0 = 1

Con la multiplicación de enteros pasa lo mismo (cuyo elemento neutro es el 1), y con la concatenación de cadenas de texto también (siendo la cadena vacía “”, el elemento neutro). Genial, ya voy entendiéndolo.

Monoides en Scalaz

Para trabajar con monoides vamos a utilizar en este post, la librería Scalaz. Scalaz ofrece un sin fin de opciones, abstracciones y funcionalidades. Hoy solo vamos a dar unas pequeñas pinceladas que nos permitirán realizar un ejemplo. Prometemos en un futuro hablar detenidamente de esta librería 🙂

Lo primero que tenemos que hacer es importar Scalaz en nuestro proyecto. Para ello, incluimos la dependencia en nuestro proyecto:

`libraryDependencies += "org.scalaz" %% "scalaz-core" % "7.1.3"`

y realizamos los siguientes imports:

```import scalaz._, Scalaz._
```

Si cotilleamos un poco por la librería, podemos encontrarnos con la clase Monoid, o la clase Semigroup. En ellas estará definida la funcionalidad de la que podremos aprovecharnos.

En la clase Monoid está definido el método zero, que servirá para indicar cual es el elemento neutro. Además, en el trait MonoidLaw, está definida la regla fundamental que tiene que cumplir un elemento neutro.

Pero, ¿dónde está la información asociada a la propiedad asociativa?. Pues está en la clase Semigroup. Parece ser que los monoides son una especialización de los semigrupos. Estos últimos, son los encargados de la regla asociativa, mientras que los monoides añaden la regla del elemento neutro. De hecho, si nos vamos a la clase Semigroup, podemos encontrar el método append, el cual representará nuestra operación binaria |+|, y un poco más abajo podemos ver como está definida la propiedad asociativa.

Lo siguiente que debemos saber es que Scalaz se basa en una estructura de type classes. Es por ello que tendremos que implementar implicit objects, definiendo el comportamiento propio de nuestras estructuras respecto a las propiedades monádicas.

Después de esta escasa pero suficiente (o eso espero) información, vamos a ver como podemos aplicar todo este conocimiento con un ejemplo sencillo.

Creando nuestro propio monoide

Ahora, para acabar, vamos a crear nuestro propio monoide con Scalaz. Vamos a comenzar creando unos nuevos tipos de datos. Vamos a crear dos tipos de átomos: oxígeno e hidrógeno.

```trait Atom
case object Oxygen extends Atom
case object Hydrogen extends Atom
```

Y para terminar, el tipo molécula. Dicho tipo tendrá un número determinado de átomos (que pueden ser de distintos tipos), y una estabilidad molecular.

```case class Molecule(atoms: Map[Atom, Int], stability: Double)
``` Queremos trabajar con nuestro tipo molécula como si fuera un monoide, para ello, utilizando las type classes de Scalaz, vamos a definir un implicit object definiendo el comportamiento monádico de la molécula (esto parece un trabalenguas):

```implicit object MoleculeIsMonoid extends Monoid[Molecule] {

def zero: Molecule = Molecule(Map(), 1)
def append(f1: Molecule, f2: => Molecule): Molecule = f1.fusion(f2)

}
```

Hemos decidido que la molécula neutra sea aquella que no tiene átomos, y que su estabilidad es 1, la máxima estabilidad posible.

Además, hemos decidido que la suma de moléculas se delegue en una función llamada fusion. Vamos a ver como está definida:

```case class Molecule(atoms: Map[Atom, Int], stability: Double) {

def fusion(other: Molecule): Molecule =
Molecule(
atoms = atoms |+| other.atoms,
stability = stability * other.stability
)
}
```

Como podemos observar, la fusión de dos moléculas consiste en sumar los átomos que las forman como si fueran monoides. Y es que resulta, que Scalaz nos proporciona funcionalidad para tratar la combinación de mapas como monoides. Además, vamos a combinar las estabilidades como si fueran probabilidades, es decir, multiplicándolas.

El método append también se puede utilizar mediante el símbolo |+|, justo como lo habíamos definido en un primer momento.

¡Y ya está! Ahora puedo fusionar moléculas aprovechándome de que son monoides, y de las operaciones que nos ofrece Scalaz con dichas abstracciones:

```val m1 = Molecule(Map(Oxygen -> 1, Hydrogen -> 2), 0.2)
val m2 = Molecule(Map(Oxygen -> 1), 0.3)

m1 |+| m2
//Molecule(Map(Oxygen -> 2, Hydrogen -> 2), 0.06)

List(m1, m2, m2, m1).foldLeft(Molecule(Map(), 1))(_ |+| _)
//Molecule(Map(Oxygen -> 4, Hydrogen -> 4), 0.0036)

Some(m1) |+| Some(m2)
//Some(Molecule(Map(Oxygen -> 2, Hydrogen -> 2), 0.06))
``` Conclusión

Cuando llegues aquí espero que hayas perdido un poco de miedo a las palabras raras. Como hemos visto, las abstracciones algebraicas, son simplemente una manera de poner nombre a elementos que cumplen una serie de propiedades. Después, podremos beneficiarnos de esta abstracción para poder tratar varias operaciones distintas de la misma forma. Esta vez le ha tocado el turno a los monoides. Más adelante llegarán otros conceptos que ya te deberían de sonar, como las famosas mónadas. Ahora ya sabes, a fardar delante de tus amigos hablando de monoides 🙂