Funtores en Cats parte 9

Hay situaciones en las que la eliminación de izquierda a derecha no es la opción correcta. Un ejemplo es el tipo O en Scalactic, que es un equivalente convencionalmente sesgado a la izquierda de O bien:

type PossibleResult = ActualResult Or Error

Otro ejemplo es el funtor contravariante para Function1.

Mientras que el funtor Function1 implementa la composición de función de izquierda a derecha, el funtor Contravariant implementa la composición de derecha a izquierda con estilo de composición. En otras palabras, las siguientes expresiones son todas equivalentes:

val func3a: Int => Double = a => func2(func1(a))

val func3b: Int => Double = func2.compose(func1)

// Hypothetical example. This won't actually compile:

val func3c: Int => Double = func2.contramap(func1)

Sin embargo, si intentamos esto de verdad, nuestro código no se compilará:

import cats.syntax.contravariant._ // for contramap

val func3c = func2.contramap(func1)

// error: value contramap is not a member of Double => Double

// val func3c = func2.contramap(func1)

//

 ^^^^^^^^^^^^^^^

El problema aquí es que la contravariante para la Function1 corrige el tipo de retorno y deja que el tipo de parámetro varíe, lo que requiere que el compilador elimine los parámetros de tipo de derecha a izquierda, como se muestra a continuación

type F[A] = A => Double

El compilador falla simplemente debido a su sesgo de izquierda a derecha. Podemos probar esto creando un alias de tipo que cambia los parámetros en la Función1:

type <=[B, A] = A => B

type F[A] = Double <= A

Si volvemos a escribir func2 como una instancia de <=, restablecemos el orden de eliminación requerido y podemos llamar a contramap como deseemos:

val func2b: Double <= Double = func2

val func3c = func2b.contramap(func1)

// func3c: Int => Double = scala.Function1$$Lambda$7919/0

x00000008424d3040@50061a2d

La diferencia entre func2 y func2b es puramente sintáctica: ambos se refieren al mismo valor y, por lo demás, los alias de tipo son completamente compatibles. Increíblemente, sin embargo, esta simple reformulación es suficiente para darle al compilador la pista que necesita para resolver el problema.

Es raro que tengamos que hacer este tipo de eliminación de derecha a izquierda. La mayoría de los constructores de tipos de parámetros múltiples están diseñados para tener un sesgo hacia la derecha, lo que requiere la eliminación de izquierda a derecha que es compatible con el compilador listo para usar. Sin embargo, es útil conocer esta peculiaridad del orden de eliminación en caso de que alguna vez te encuentres con un escenario extraño como el anterior.

Funtores en Cats parte 8

Vimos una instancia de functor para Function1. 

import cats.Functor

import cats.instances.function._ // for Functor

import cats.syntax.functor._

 // for map

val func1 = (x: Int)  => x.toDouble

val func2 = (y: Double) => y * 2

val func3 = func1.map(func2)

// func3: Int => Double = scala.Function1$$Lambda$7919/0

Function1 tiene dos parámetros de tipo (el argumento de la función y el tipo de resultado):

trait Function1[-A, +B] {

  def apply(arg: A): B

}

Sin embargo, Functor acepta un constructor de tipos con un parámetro:

trait Functor[F[_]] {

  def map[A, B](fa: F[A])(func: A => B): F[B]

}

El compilador tiene que corregir uno de los dos parámetros de Function1 para crear un constructor de tipos del tipo correcto para pasar a Functor. Tiene dos opciones a elegir:

type F[A] = Int => A

type F[A] = A => Double

Sabemos que la primera de ellas es la elección correcta. Sin embargo, el compilador no entiende lo que significa el código. En cambio, se basa en una regla simple, implementando lo que se llama "unificación parcial".

La unificación parcial en el compilador de Scala funciona fijando los parámetros de tipo de izquierda a derecha. En el ejemplo anterior, el compilador corrige Int en Int => Double y busca un Functor para funciones de tipo Int => ?:

type F[A] = Int => A

val functor = Functor[F]

Esta eliminación de izquierda a derecha funciona para una amplia variedad de escenarios comunes, incluidos Functors para tipos como Function1 y Either:

val either: Either[String, Int] = Right(123)

// either: Either[String, Int] = Right(123)

either.map(_ + 1)

// res0: Either[String, Int] = Right(124)

Funtores en Cats parte 7

Entre otros tipos, Cats proporciona una instancia de Invariant para Monoid. 

Imagina que queremos producir un monoide para el tipo símbolo de Scala. Cats no proporciona un Monoide para Símbolo, pero sí proporciona un Monoide para un tipo similar: Cadena o String. Podemos escribir nuestro nuevo semigrupo con un método vacío que se basa en la cadena vacía y un método de combinación que funciona de la siguiente manera:

1. aceptar dos Símbolos como parámetros;
2. convertir los Símbolos a Cadenas;
3. combine las cadenas usando Monoid[String];
4. convertir el resultado de nuevo en un Símbolo.

Podemos implementar combine usando imap, pasando funciones de tipo String =>Symbol y Symbol => String como parámetros. Aquí está el código, escrito usando el método de extensión imap proporcionado por cats.syntax.invariant:

import cats.Monoid

import cats.instances.string._ // for Monoid

import cats.syntax.invariant._ // for imap

import cats.syntax.semigroup._ // for |+|

implicit val symbolMonoid: Monoid[Symbol] = Monoid[String].imap(Symbol.apply)(_.name) 

Monoid[Symbol].empty

// res3: Symbol = '

Symbol("a") |+| Symbol("few") |+| Symbol("words")

// res4: Symbol = 'afewwords

Funtores en Cats parte 6

Veamos la implementación de funtores contravariantes e invariantes en Cats, proporcionados por las clases de tipos cats.Contravariant y cats.Invariant.

trait Contravariant[F[_]] {

def contramap[A, B](fa: F[A])(f: B => A): F[B]

}

trait Invariant[F[_]] {

def imap[A, B](fa: F[A])(f: A => B)(g: B => A): F[B]

}

Podemos invocar instancias de Contravariant utilizando el método Contravariant.apply. Cats proporciona instancias para tipos de datos que consumen parámetros, incluidos Eq, Show y Function1. 

Veamos un ejemplo:

import cats.Contravariant

import cats.Show

import cats.instances.string._

val showString = Show[String]

val showSymbol = Contravariant[Show].contramap(showString)((sym: Symbol) => s"'${sym.name}")

showSymbol.show(Symbol("dave"))

// res1: String = "'dave"

Más convenientemente, podemos usar cats.syntax.contravariant, que proporciona un método de extensión de contramap:

import cats.syntax.contravariant._ // for contramap

showString.contramap[Symbol](sym => s"'${sym.name}").show(Symbol("dave"))

// res2: String = "'dave"

Funtores en Cats parte 5

Podemos pensar en el método map de Functor como "agregar" una transformación a una cadena. Ahora vamos a ver otras dos type class, una que representa anteponer operaciones a una cadena y otra que representa la construcción de una cadena bidireccional de operaciones. Estos se denominan funtores contravariantes e invariantes respectivamente.

La primera de nuestras clases de tipos, el funtor contravariante, proporciona una operación llamada contramapa que representa "anteponer" una operación a una cadena. 

El método contramap solo tiene sentido para tipos de datos que representan transformaciones. Por ejemplo, no podemos definir un contramapa para una opción porque no hay forma de retroalimentar un valor en un Option[B] a través de una función A => B. Sin embargo, podemos definir un contramapa para la clase de tipo Imprimible :

trait Printable[A] {

  def format(value: A): String

}

Un Printable[A] representa una transformación de A a String. Su método contramapa acepta una función func de tipo B => A y crea un nuevo Imprimible[B]:

trait Printable[A] {

  def format(value: A): String

  def contramap[B](func: B => A): Printable[B] = ???

}

def format[A](value: A)(implicit p: Printable[A]): String = p.format(value)

Los funtores invariantes implementan un método llamado imap que es informalmente equivalente a una combinación de map y contramap. Si map genera nuevas instancias de clase de tipo agregando una función a una cadena y contramap las genera anteponiendo una operación a una cadena, imap las genera a través de un par de transformaciones bidireccionales.

Los ejemplos más intuitivos de esto son una clase de tipo que representa la codificación y decodificación como algún tipo de datos, como el formato Play JSON y el códec de scodec. Podemos crear nuestro propio códec mejorando Imprimible para admitir la codificación y decodificación hacia/desde una cadena:

trait Codec[A] {

def encode(value: A): String

def decode(value: String): A

def imap[B](dec: A => B, enc: B => A): Codec[B] = ???

}

def encode[A](value: A)(implicit c: Codec[A]): String =

c.encode(value)

def decode[A](value: String)(implicit c: Codec[A]): A =

c.decode(value)

Si tenemos un Codec[A] y un par de funciones A => B y B => A, el método imap crea un Codec[B]:

Como ejemplo de caso de uso, imagina que tenemos un Codec[String] básico, cuyos métodos de codificación y decodificación simplemente devuelven el valor que se les pasa:

implicit val stringCodec: Codec[String] =

new Codec[String] {

def encode(value: String): String = value

def decode(value: String): String = value

}

Podemos construir muchos códecs útiles para otros tipos construyendo a partir de stringCodec usando imap:

implicit val intCodec: Codec[Int] =

stringCodec.imap(_.toInt, _.toString)

implicit val booleanCodec: Codec[Boolean] =

stringCodec.imap(_.toBoolean, _.toString)

Funtores en Cats parte 4

Podemos definir un funtor simplemente definiendo su método map. Aquí hay un ejemplo de un Functor para Option, aunque tal cosa ya existe en cats.instances. La implementación es trivial: simplemente llamamos al método de mapa de Option:

implicit val optionFunctor: Functor[Option] = new Functor[Option] {

   def map[A, B](value: Option[A])(func: A => B): Option[B] = value.map(func)

}

A veces necesitamos inyectar dependencias en nuestras instancias. Por ejemplo, si tuviéramos que definir un Functor personalizado para Future (otro ejemplo hipotético: Cats proporciona uno en cats.instances.future), tendríamos que tener en cuenta el parámetro ExecutionContext implícito en future.map. No podemos agregar parámetros adicionales a functor.map, por lo que debemos tener en cuenta la dependencia cuando creamos la instancia:

import scala.concurrent.{Future, ExecutionContext}

implicit def futureFunctor(implicit ec: ExecutionContext): Functor[Future] = new Functor[Future] {

  def map[A, B](value: Future[A])(func: A => B): Future[B] = value.map(func)

}

Cada vez que llamamos a un Functor for Future, ya sea directamente usando Functor.apply o indirectamente a través del método de extensión map, el compilador ubicará futureFunctor por resolución implícita y buscará recursivamente un ExecutionContext en el sitio de la llamada. Así es como se vería la expansión:

// We write this:

Functor[Future]

// The compiler expands to this first:

Functor[Future](futureFunctor)

// And then to this:

Functor[Future](futureFunctor(executionContext))

Funtores en Cats parte 3

El método principal proporcionado por la sintaxis de Functor es map. Es difícil demostrar esto con Opciones y Listas, ya que tienen sus propios métodos de mapa integrados y el compilador de Scala siempre preferirá un método integrado a un método de extensión. Resolveremos esto con dos ejemplos. Primero veamos el map sobre funciones. El tipo Function1 de Scala no tiene un método de map (se llama andThen en su lugar), por lo que no hay conflictos de nombres:

import cats.instances.function._ // for Functor

import cats.syntax.functor._ // for map

val func1 = (a: Int) => a + 1

val func2 = (a: Int) => a * 2

val func3 = (a: Int) => s"${a}!"

val func4 = func1.map(func2).map(func3)

func4(123)

// res3: String = "248!"

Veamos otro ejemplo. Esta vez vamos a abstraernos de los funtores para no trabajar con ningún tipo concreto en particular. Podemos escribir un método que aplique una ecuación a un número sin importar en qué contexto del funtor se encuentre:

def doMath[F[_]](start: F[Int])(implicit functor: Functor[F]): F[Int] = start.map(n => n + 1 * 2)

import cats.instances.option._ // for Functor

import cats.instances.list._  // for Functor

doMath(Option(20))

// res4: Option[Int] = Some(22)

doMath(List(1, 2, 3))

// res5: List[Int] = List(3, 4, 5)

Para ilustrar cómo funciona esto, echemos un vistazo a la definición del método map en cats.syntax.functor. Aquí hay una versión simplificada del código:

implicit class FunctorOps[F[_], A](src: F[A]) {

  def map[B](func: A => B)(implicit functor: Functor[F]): F[B] = functor.map(src)(func)

}

El compilador puede usar este método de extensión para insertar un método map donde no haya un map integrado disponible:

foo.map(value => value + 1)

Suponiendo que foo no tiene un método de map incorporado, el compilador detecta el error potencial y envuelve la expresión en un FunctorOps para corregir el código:

new FunctorOps(foo).map(value => value + 1)

El método map de FunctorOps requiere un Functor implícito como parámetro. Esto significa que este código solo se compilará si tenemos un Funtor para F en el alcance. Si no lo hacemos, obtenemos un error del compilador:

final case class Box[A](value: A)

val box = Box[Int](123)

box.map(value => value + 1)

// error: value map is not a member of repl.Session.App0.Box[Int]

// box.map(value => value + 1)

// ^^^^^^^

El método as también está disponible como sintaxis.

List(1, 2, 3).as("As")

// res7: List[String] = List("As", "As", "As")

Funtores en Cats parte 2

La clase de tipo de funtor es cats.Functor. Obtenemos instancias usando el método Functor.apply estándar de un objeto complementario. Como es habitual, las instancias predeterminadas se organizan por tipo en el paquete cats.instances:

import cats.Functor

import cats.instances.list._

 // for Functor

import cats.instances.option._ // for Functor

val list1 = List(1, 2, 3)

// list1: List[Int] = List(1, 2, 3)

val list2 = Functor[List].map(list1)(_ * 2)

// list2: List[Int] = List(2, 4, 6)

val option1 = Option(123)

// option1: Option[Int] = Some(123)

val option2 = Functor[Option].map(option1)(_.toString)

// option2: Option[String] = Some("123")

Functor proporciona un método llamado lift, que convierte una función de tipo A => B en una que opera sobre un funtor y tiene tipo F[A] => F[B]:

val func = (x: Int) => x + 1

// func: Int => Int = <function1>

val liftedFunc = Functor[Option].lift(func)

// liftedFunc: Option[Int] => Option[Int] = cats.Functor$$Lambda$7972

/0x000000084250f840@195657fa

liftedFunc(Option(1))

// res1: Option[Int] = Some(2)

El método as es el otro método que es probable que utilice. Reemplaza con value dentro del Functor con el valor dado.

Functor[List].as(list1, "As")

// res2: List[String] = List("As", "As", "As")

Funtores en Cats

Formalmente, un funtor es un tipo F[A] con un map de tipo (A => B) => F[B]. 

Cats codifica Functor como una clase de tipos, cats.Functor, por lo que el método se ve un poco diferente. Acepta la F[A] inicial como parámetro junto con la función de transformación. Aquí hay una versión simplificada de la definición:

package cats

trait Functor[F[_]] {

   def map[A, B](fa: F[A])(f: A => B): F[B]

}

Los funtores garantizan la misma semántica ya sea que secuenciamos muchas operaciones pequeñas una por una o las combinemos en una función más grande antes de llamar a map. Para garantizar que esto sea así, deben cumplirse las siguientes leyes: Identidad: llamar a map con la función de identidad es lo mismo que no hacer nada: 

fa.map(a => a) == fa

Composición: llamar a map con dos funciones f y g es lo mismo que llamar a map con f y luego con g:

fa.map(g(f(_))) == fa.map(f).map(g)

Funtores parte 2

Seguimos con Funtores 

Los métodos de map de List, Option y Either aplican funciones de forma eager (es decir no lazy). Sin embargo, la idea de secuenciar cálculos es más general que esto. Investiguemos el comportamiento de algunos otros funtores que aplican el patrón de diferentes maneras.

Futures : Future es un funtor que secuencia cálculos asincrónicos poniéndolos en cola y aplicándolos a medida que se completan sus predecesores. La firma de tipo de su método de map, tiene la misma forma que las firmas anteriores. Sin embargo, el comportamiento es muy diferente. Cuando trabajamos con un Futuro no tenemos garantías sobre su estado interno. El cálculo envuelto puede estar en curso, completo o rechazado. Si el futuro está completo, nuestra función de map se puede llamar inmediatamente. De lo contrario, algún grupo de subprocesos subyacente pone en cola la llamada de función y vuelve a ella más tarde. No sabemos cuándo se llamará a nuestras funciones, pero sí sabemos en qué orden se llamarán. De esta manera, Future proporciona el mismo comportamiento de secuencia que se ve en List, Option y Either:

import scala.concurrent.{Future, Await}

import scala.concurrent.ExecutionContext.Implicits.global

import scala.concurrent.duration._

val future: Future[String] =

    Future(123).

    map(n => n + 1).

    map(n => n * 2).

    map(n => s"${n}!")

Await.result(future, 1.second)

// res2: String = "248!"

Tenga en cuenta que los futuros de Scala no son un gran ejemplo de programación funcional pura porque no son referencialmente transparentes. Future siempre calcula y almacena en caché un resultado y no hay forma de que modifiquemos este comportamiento. Esto significa que podemos obtener resultados impredecibles cuando usamos Future para envolver cálculos de efectos secundarios. Por ejemplo:

import scala.util.Random

val future1 = {

  // Initialize Random with a fixed seed:

  val r = new Random(0L)

  // nextInt has the side-effect of moving to

  // the next random number in the sequence:

  val x = Future(r.nextInt)

  for {

    a <- x

    b <- x

  } yield (a, b)

}

val future2 = {

  val r = new Random(0L)

  for {

    a <- Future(r.nextInt)

    b <- Future(r.nextInt)

  } yield (a, b)

}

val result1 = Await.result(future1, 1.second)

// result1: (Int, Int) = (-1155484576, -1155484576)

val result2 = Await.result(future2, 1.second)

// result2: (Int, Int) = (-1155484576, -723955400)

Idealmente, nos gustaría que resultado1 y resultado2 contuvieran el mismo valor. Sin embargo, el cálculo de future1 llama a nextInt una vez y el cálculo de future2 lo llama dos veces. Porque nextInt devuelve un resultado diferente cada vez que obtenemos un resultado diferente en cada caso.

Este tipo de discrepancia hace que sea difícil razonar acerca de los programas que involucran Futuros y efectos secundarios. También hay otros aspectos problemáticos del comportamiento de Future, como la forma en que siempre inicia los cálculos inmediatamente en lugar de permitir que el usuario dicte cuándo debe ejecutarse el programa. 

Cuando miramos Cats Effect, veremos que el tipo IO resuelve estos problemas. Si Future no es referencialmente transparente, tal vez deberíamos buscar otro tipo de datos similar que lo sea. Pero de él hablaremos el proximo post. 

Funtores

Los funtores son una abstracción que nos permite representar secuencias de operaciones dentro de un contexto como una Lista, un Option o cualquiera de miles de otras posibilidades. Los funtores por sí solos no son tan útiles, pero los casos especiales de funtores, como las mónadas y los funtores aplicativos, son algunas de las abstracciones más utilizadas.

Informalmente, un funtor es cualquier cosa con un método map. Probablemente conozca muchos tipos que tienen esto: Option, List, y Either, por nombrar algunos. Por lo general, nos encontramos primero con el map cuando iteramos sobre Listas. Sin embargo, para entender los funtores necesitamos pensar en el método de otra manera. En lugar de recorrer la lista, deberíamos pensar en ella como transformar todos los valores dentro de una sola vez. Especificamos la función que se va a aplicar y el map se asegura de que se aplique a cada elemento. Los valores cambian pero la estructura de la lista (el número de elementos y su orden) permanece igual:

List(1, 2, 3).map(n => n + 1)

// res0: List[Int] = List(2, 3, 4)

De manera similar, cuando asignamos una opción, transformamos los contenidos pero dejamos el contexto Some o None sin cambios. El mismo principio se aplica a Either con sus contextos Left y Right. Esta noción general de transformación, junto con el patrón común de firmas de tipo, es lo que conecta el comportamiento del mapa en diferentes tipos de datos.

Debido a que map deja la estructura del contexto sin cambios, podemos llamarlo repetidamente para secuenciar múltiples cálculos sobre el contenido de una estructura de datos inicial:

List(1, 2, 3).

map(n => n + 1).

map(n => n * 2).

map(n => s"${n}!")

// res1: List[String] = List("4!", "6!", "8!")

Deberíamos pensar en el map no como un patrón de iteración, sino como una forma de secuenciar cálculos sobre valores ignorando algunas complicaciones dictadas por el tipo de datos relevante: