DEV Community: Ivan Lorenz

¿Es Validated un Applicative?

Ivan Lorenz — Fri, 19 Nov 2021 08:41:09 +0000

Preguntas y respuestas sobre las sesiones live coding de Arrow.

La siguiente pregunta fue realizada durante la tercera sesión. Os dejamos también el enlace directo a la discusión en Github y el enlace del vídeo en el momento de la pregunta.

Pregunta

Hoy nos toca una pregunta cerrada: ¿es Validated un Applicative?. Intentaremos desarrollar un poco la respuesta.

Respuesta

Durante la sesión no respondimos por varias razones: la primera es que intentamos guiar estas sesiones explicando el porqué y cómo introducir Arrow en nuestro código Kotlin en el back-end. Hemos preferido centrarnos en las características que nos ofrecen tipos cómo Either, Validated o NonEmptyList en nuestro trabajo diario con código OOP y cómo incorporarlos a nuestro código base, que en la teoría matemática formal que los sustenta, la Teoría de categorías. La segunda es que durante las primeras dos sesiones, no queríamos hablar de FP. Nos lo reservamos para las siguientes sesiones.

De hecho, estas sesiones pretender simular un caso de uso sintético de migración iterativa, más o menos exportable a nuestro día a día, desde OOP a FP usando Kotlin y Arrow. Lo hacemos, no porqué creamos que un paradigma de programación sea mejor que el otro en términos absolutos, sino porqué pensamos que en el contexto del desarrollo de aplicaciones en Internet escalables de ciertas dimensiones y cambio constante, la FP puede ayudar mucho a entender el código y a aumentar su rendimiento de forma, creemos, más sencilla que la OOP.

Volviendo a la pregunta, ¿es Validated un Applicative?

La única forma de demostrarlo es haciendo una verificación formal, comprobando que Validated cumple con las leyes matemáticas cómo Functor así cómo también cumple con las leyes matemáticas de Applicative Functor.

Hemos creado un pequeño test ValidatedAsApplicativeTest con Kotest para comprobar estas propiedades. De todos modos, Validated además de ser un Functor y un Applicative, es también un Type Constructor, concretamente construye Coproducts o Sum types del tipo Valid o Invalid para pares de tipos concretos. Los test que hemos hecho utilizan Validated<Nothing, String?> y ValidatedNel<String?, String?>. Ésta es una desventaja que tiene la programación en Kotlin con las matemáticas. Debo crear instancias concretas de tipos para poder utilizarlos en test y por tanto, estoy comprobando únicamente esas leyes para esos tipos concretos, y no para todos los tipos que Validated puede construir.

Conservación de los morfismos de identidad.

"Validated functor must preserve identity arrows" {
  checkAll(genNullableString) { a ->
    identity(a.valid()) shouldBe identity(a).valid()
    identity(a.invalid()) shouldBe identity(a).invalid()
  }
}

Conservación de la composición de morfismos.

"Validated functor must preserve function composition" {
  checkAll(genNullableString) { a ->
    val f = { b: String? -> "PRE-APPENDED${b}" }
    val g = { b: String? -> "${b}POST-APPENDED" }
    g.compose(f)(a).valid() shouldBe a.valid().map(g.compose(f))
    g.compose(f)(a).invalid() shouldBe a.invalid().mapLeft(g.compose(f))
  }
}

Identidad.

"Validated applicative must satisfy identity law" {
  checkAll(genValidated) { validated ->
    val validatedId = Validated.lift<NonEmptyList<String>, String?, String?>{ a -> identity(a) }
    validatedId(validated) shouldBe validated
  }
}

Homomorfismo.

"Validated applicative must satisfy homomorphism law" {
  checkAll(genNullableString) { a ->
    val f = { b: String? -> "PRE-APPENDED${b}" }
    val validatedF = Validated.lift<Nothing, String?, String?>(f)
    validatedF(a.valid()) shouldBe f(a).valid()
  }
}

Intercambio.

 "Validated applicative must satisfy interchange law" {
  checkAll(genNullableString) { a ->
    val f = { b: String? -> "PRE-APPENDED${b}" }
    val validatedF1 = Validated.lift<Nothing, String?, String?>(f)
    val validatedF2 = Validated.lift<Nothing, (String?) -> String?, String?> { f -> f(a) }
    validatedF1(a.valid()) shouldBe validatedF2(f.valid())
  }
}

Composición.

"Validated applicative must satisfy composition law" {
  checkAll(genNullableString) { a ->
    val f = { b: String? -> "PRE-APPENDED${b}" }
    val g = { b: String? -> "${b}POST-APPENDED" }
    val validatedF1 = Validated.lift<Nothing, String?, String?>(f)
    val validatedF2 = Validated.lift<Nothing, String?, String?>(g)
    (validatedF2.compose(validatedF1))(a.valid()) shouldBe validatedF1(validatedF2(a.valid()))
  }
}

Hemos utilizado la función lift de Validated para comprobar estas leyes, inspirados en la definición formal de estas leyes en Haskell. Sin embargo, preguntando a la comunidad de Arrow nos comentaron que aunque son correctas, sería mas idiomático verificarlas usando la función zip de Validated. Es un ejercicio que queda pendiente.Y si queréis contribuir con ello haciendo una PR a nuestro repo será más que bienvenida.

Encontrarás las verificaciones formales matemáticas de Functor y Applicative en The Dao of Functional Programming de @BartoszMilewski. Libro que te recomiendo si te quieres introducir en Teoría de categorías.

Either vs Try (vs Result)

Ivan Lorenz — Tue, 16 Nov 2021 12:59:34 +0000

Preguntas y respuestas sobre las sesiones live coding de Arrow.

La siguiente pregunta fue realizada durante la segunda sesión. Os dejamos también el enlace directo a la discusión en Github.

Pregunta

Para captura de excepciones presentasteis Either<L,R>. Arrow incluye Try<T> y la librería standard de Kotlin incluye Result<T>.

Arrow ya tiene Try marcada como deprecated porque no se alinea del todo con los principios de programación (paradigma?) que promueve Arrow.

La lib estándar de Kotlin incluye Result que parece una mezcla de Try y Option. Tampoco es demasiado limpio en mi opinión.

Hoy (en relación al 23 de septiembre) Alex Nedelcu ha hecho una twitter poll (ligeramente) relacionada con este tema.

Alex Nedelcu

@alexelcu

Are you a Try person, or a try/catch person?

09:57 AM - 23 Sep 2021

Podrías desarrollar los pros/cons de usar Either en comparación con las otras opciones que existen?

Respuesta

Primero déjame establecer el contexto de nuestra respuesta, porque sin un contexto no hay explicación que se sostenga. En mi equipo en @adevintaeng desarrollamos aplicaciones distribuidas con Kotlin. Hemos encontrado valor en usar métodos monádicos en programación OO. Nos interesa la componibilidad y la expresividad de tipos como Either<L,R> y los patrones de gestión de errores que facilita, cómo mostramos en esta segunda sesión. Desarrollando sistemas distribuidos sabemos que la gestión de errores, su diseño y su evolución, es la clave para crear aplicaciones resilientes y tolerantes al fallo.

En este contexto encontramos el uso de la librería Arrow Core un perfecto compañero de viaje. Parte del trabajo de un ingeniero de software es asegurarse que las librerías que utiliza van a ser una ayuda para acelerar el desarrollo a la vez que no van a representar un problema en el futuro, como librerías no mantenidas o sin una estrategia de evolución sólida y solvente. En cuanto empezamos a utilizar Arrow 0.13.2, el tipo Try<T> ya estaba obsoleto y eliminado desde la versión 0.11. Y el tipo Option<T> estaba siendo cuestionado por los mismos creadores de Arrow. Así que recomendaban el uso de Either<L,R> desde la versión 0.13.2 para garantizar la compatibilidad total con la primera versión general de Arrow 1.0.0.

Desde el punto de vista de un programador que utiliza la librería para sus aplicaciones en producción, esta debería ser una explicación suficiente para utilizar Either<L, R> frente a las otras opciones. Pero podemos elaborar más las razones.

Try<T> fue marcado cómo obsoleto en Arrow en el mismo momento que se decidió marcar cómo obsoleto IO monad y basar la estrategia de convertir las funciones con efectos laterales en funciones puras con el uso de Kotlin suspend. Marcando una función con suspend la ejecución de esa función devuelve una descripción del efecto, es decir el efecto no se produce si no la provees con un contexto, en este caso una Coroutine. Si quieres profundizar más en el porqué, aquí encontrarás el porque del cambio de estrategia.

Bien, que pasaba con Try<T>? El primer problema es que Try no podía diferir la ejecución del efecto de ningún modo y retornar únicamente una descripción del efecto porque sus constructores "evaluaban ansiosamente" - Dios, que difícil es intentar escribir en español sobre cualquier tema de ingeniería del software - a.k.a eager evaluation . Puedes ampliar detalles sobre los tipos de evaluación en Lazy, eager and greedy evaluation.

El segundo problema es que Try<T> no es seguro. Porqué? Básicamente porque puedes capturar cualquier Throwable que desees. Y si quieres tener control sobre una computación concurrente o paralela en la que se usa, no querrás que Try<T> pueda capturar InterruptedException o CancellationException entre otros.

Y éste es exactamente el mismo problema con Result<T> en Kotlin. De hecho, Result<T> es el tipo que se debe usar en vez de Try<T> para los caso de uso que así lo requieran.

Por todo esto, en Arrow se implementó Either.catch, que es el camino a seguir para aislar nuestro código de librerías "impuras".

En cuanto a Option<T> hubo bastante debate al respecto sobre si eliminar su uso en beneficio de un más idiomático - en Kotlin - Nullable types, porque se apreciaba poca aportación de valor sobre esto tipos. Además se indicaba que Option<T>no era más que (o si lo prefieres, es isomórfico a)

typealias Option<A> = Either<Unit, A>.

Pero después del largo debate @raulraja anunció que mantendrían Option<T> en Arrow Core 1.0.0 cómo así ha sido, porque existían algunos casos de uso en que todavía aportaba valor cómo con RxJava que declara Observable<T> y no permite null.

Cómo ves, muchas de las razones se basan en cuestiones de la programación funcional cómo lazy evaluation o en cómo convertir en declarativos los efectos laterales de una función y diferir su ejecución en un entorno seguro. Nosotros todavía no estamos utilizando Arrow Fx ni estamos marcando nuestras funciones cómo suspended, pero lo haremos si le encontramos valor para nuestros casos de usos y por supuesto, lo explicaremos en otras sesiones.

Espero que haya podido aclarar un poco tus dudas. Y no dudéis en matizar o corregir algún punto que no haya explicado con claridad o que mi memoria haya hecho desviar de la verdad. Obviamente, los que mejor pueden explicar esto son @raulraja , @47deg y los contributors del proyecto Arrow, a los que de paso, les doy las gracias por esta magnífica librería.