Hola Habr

Hoy consideraremos un patrón de FP como Has -class. Esto es algo bastante interesante por varias razones: en primer lugar, nos aseguraremos una vez más de que haya patrones en el FP. En segundo lugar, resulta que la implementación de este patrón puede confiarse a la máquina, lo que resultó ser un truco bastante interesante con las clases de tipos (y la biblioteca Hackage), que una vez más demuestra la utilidad práctica de las extensiones del sistema de tipos fuera de Haskell 2010 e IMHO es mucho más interesante que este patrón en sí. En tercer lugar, una ocasión para gatos.

Sin embargo, quizás valga la pena comenzar con una descripción de lo que es una clase Has , especialmente porque no había una descripción breve (y, especialmente, una en ruso) de la misma.

Entonces, ¿cómo resuelve Haskell el problema de administrar un entorno global de solo lectura que necesitan varias funciones diferentes? ¿Cómo, por ejemplo, se expresa la configuración global de la aplicación?

La solución más obvia y directa es que si una función necesita un valor de tipo Env , ¡simplemente puede pasar un valor de tipo Env a esta función!

 iNeedEnv :: Env -> Foo iNeedEnv env = -- ,  env    

Sin embargo, desafortunadamente, dicha función no es muy componible, especialmente en comparación con algunos otros objetos a los que estamos acostumbrados en Haskell. Por ejemplo, en comparación con las mónadas.

En realidad, una solución más generalizada es envolver funciones que necesitan acceso al entorno Env en la mónada Reader Env :

 import Control.Monad.Reader data Env = Env { someConfigVariable :: Int , otherConfigVariable :: [String] } iNeedEnv :: Reader Env Foo iNeedEnv = do --    : env <- ask --  c    : theInt <- asks someConfigVariable ... 

Esto se puede generalizar aún más, para lo cual es suficiente usar la clase de tipo MonadReader y simplemente cambiar el tipo de función:

 iNeedEnv :: MonadReader Env m => m Foo iNeedEnv = --     ,    

Ahora no nos importa exactamente en qué pila monádica estamos, siempre y cuando podamos obtener el valor del tipo Env (y expresamente lo expresamos en el tipo de nuestra función). No nos importa si toda la pila tiene otras características como IO o manejo de errores a través de MonadError :

 someCaller :: (MonadIO m, MonadReader Env m, MonadError Err m) => m Bar someCaller = do theFoo <- iNeedEnv ... 

Y, por cierto, un poco más alto, en realidad mentí cuando dije que el enfoque de pasar explícitamente un argumento a una función no es tan componible como las mónadas: el tipo funcional "parcialmente aplicado" r -> es una mónada, y, además, es bastante una instancia legítima de la clase MonadReader r . El desarrollo de la intuición apropiada se ofrece al lector como un ejercicio.

En cualquier caso, este es un buen paso hacia la modularidad. Veamos a dónde nos lleva.

Por qué tiene

Trabajemos en algún tipo de servicio web, que, entre otras cosas, puede tener los siguientes componentes:

• Capa de acceso a la base de datos
• servidor web
• temporizador activado módulo similar al cron.

Cada uno de estos módulos puede tener su propia configuración:

• detalles de acceso a la base de datos,
• host y puerto para el servidor web,
• intervalo de operación del temporizador.

Podemos decir que la configuración general de toda la aplicación es una combinación de todas estas configuraciones (y, probablemente, algo más).

Para simplificar, suponga que la API de cada módulo consta de una sola función:

• setupDatabase
• startServer
• runCronJobs

Cada una de estas características requiere una configuración adecuada. Ya aprendimos que MonadReader es una buena práctica, pero ¿cuál será el tipo de entorno?

La solución más obvia sería algo así como

 data AppConfig = AppConfig { dbCredentials :: DbCredentials , serverAddress :: (Host, Port) , cronPeriodicity :: Ratio Int } setupDatabase :: MonadReader AppConfig m => m Db startServer :: MonadReader AppConfig m => m Server runCronJobs :: MonadReader AppConfig m => m () 

Lo más probable es que estas características requieran MonadIO y, posiblemente, algo más, pero esto no es tan importante para nuestra discusión.

De hecho, acabamos de hacer algo terrible. Por qué Bueno, de improviso:

1. Hemos agregado una conexión innecesaria entre componentes completamente diferentes. Idealmente, la capa DB no debería saber nada sobre algún tipo de servidor web. Y, por supuesto, no debemos volver a compilar el módulo para trabajar con la base de datos al cambiar la lista de opciones de configuración para el servidor web.
2. Esto no funcionará en absoluto si no podemos editar el código fuente de algunos de los módulos. Por ejemplo, ¿qué debo hacer si el módulo cron está implementado en una biblioteca de terceros que no sabe nada sobre nuestro caso de usuario específico?
3. Agregamos oportunidades para cometer un error. Por ejemplo, ¿qué es serverAddress ? ¿Es esta la dirección que el servidor web debe escuchar, o es la dirección del servidor de la base de datos? El uso de un tipo grande para todas las opciones aumenta la posibilidad de tales colisiones.
4. Ya no podemos concluir de un vistazo a las firmas de funciones qué módulos usan qué parte de la configuración. ¡Todo tiene acceso a todo!

Entonces, ¿cuál es la solución para todo esto? Como se puede adivinar por el título del artículo, esto

Has patrón

De hecho, a cada módulo no le importa el tipo de entorno completo, siempre que este tipo tenga los datos necesarios para el módulo. Esto es más fácil de mostrar con un ejemplo.

Considere un módulo para trabajar con una base de datos y suponga que define un tipo que contiene toda la configuración que necesita el módulo:

 data DbConfig = DbConfig { dbCredentials :: DbCredentials , ... } 

Has -pattern se representa como la siguiente clase de tipo:

 class HasDbConfig rec where getDbConfig :: rec -> DbConfig 

Entonces el tipo setupDatabase se verá así

 setupDatabase :: (MonadReader rm, HasDbConfig r) => m Db 

y en el cuerpo de la función solo tenemos que usar asks $ foo . getDbConfig asks $ foo . getDbConfig donde usamos asks foo antes, debido a la capa de abstracción adicional que acabamos de agregar.

Del mismo modo, tendremos las HasWebServerConfig HasCronConfig y HasCronConfig .

¿Qué pasa si alguna función usa dos módulos diferentes? ¡Solo restricciones compatibles!

 doSmthWithDbAndCron :: (MonadReader rm, HasDbConfig r, HasCronConfig r) => ... 

¿Qué pasa con las implementaciones de estas clases de tipos?

Todavía tenemos AppConfig en el nivel más alto de nuestra aplicación (justo ahora los módulos no lo saben), y para ello podemos escribir:

 data AppConfig = AppConfig { dbConfig :: DbConfig , webServerConfig :: WebServerConfig , cronConfig :: CronConfig } instance HasDbConfig AppConfig where getDbConfig = dbConfig instance HasWebServerConfig AppConfig where getWebServerConfig = webServerCOnfig instance HasCronConfig AppConfig where getCronConfig = cronConfig 

Se ve bien hasta ahora. Sin embargo, este enfoque tiene un problema: demasiada escritura , y lo examinaremos con más detalle en la próxima publicación.