¿Las funciones de envoltura en un transformador de mónada se deben considerar como malas prácticas?

Question

Digamos que queremos usar ReaderT [(a,b)] sobre la mónada Maybe, y luego queremos hacer una búsqueda en la lista.

Ahora una manera fácil, y no demasiado raro esto es:

primera posibilidad

find a = ReaderT (lookup a) 

Sin embargo, parece como éste afirma algo no trivial acerca de cómo funciona el transformador ReaderT . Si miramos el código fuente de Control.Monad.Reader, queda claro que esto funciona bien. Pero no he leído ninguna documentación que respalde esto. Sin embargo, también podríamos escribir encontrar de esta manera:

segunda posibilidad

find a = do y <- ask 
      lift (lookup a y) 

Ideas similares se aplican para envolver MaybeT, StateT, State y Reader. Normalmente escribo algo así como el primer ejemplo, pero la mayoría de las veces es muy obvio cómo escribirlo como el segundo ejemplo, y hasta podrías decir que es más legible. Entonces mi pregunta es: ¿debería el código como el primer ejemplo considerarse malo?

Answer 1

La versión actual de la biblioteca mtl - que se basa en la biblioteca de transformadores - exporta la función reader :: (r -> a) -> Reader r a precisamente para este propósito cuando se utiliza la sencilla Reader mónada. Entonces vemos que el diseño de la biblioteca tiene en cuenta este uso. Como no se proporciona dicha función para ReaderT, podemos decir con cierta seguridad que la forma oficialmente admitida de hacerlo con ReaderT es usar el constructor directamente.

Estoy de acuerdo con usted si usted dice que un análogo readerT :: Monad m => (r -> a) -> ReaderT r m a debe agregarse a la biblioteca.Sería bueno tanto por coherencia como por permitir la posibilidad de cambiar la representación interna algún día sin romper el código de nadie.

Pero por ahora, su "primera posibilidad" es el camino a seguir.

Answer 2

Creo que el mayor problema con la primera forma es:

Si los autores MTL (o lo que sea transformador de la biblioteca que usa), deciden dejar de exportar el constructor de datos para ReaderT entonces dejará de funcionar. Esto sucedió con la mónada de estado en el bache de versión de mtl 1 a mtl 2 y es bastante molesto. Mientras que, ask es parte de la API oficial de Reader y debe planear que se quede.

Por otro lado, no consideraría la primera forma incorrecta.

Answer 3

Al menos hay una diferencia de velocidad.

Escribí un program, que usa un gen aleatorio como un estado y debe generar unos 5000000 valores aleatorios mientras se ejecuta. Consideremos ahora estas dos funciones, que ruedan un dado:

random16 = State $ randomR (1,6) -- Using the internal representation 
random16' = do 
      s <- get 
      (r,s') <- randomR (1,6) s 
      put s' 
      return r 

con el primero de ellos, el programa se ejecuta en aproximadamente 6 segundos, mientras que el segundo es mucho más lento, teniendo unos 8 segundos. Puedo crear una imagen, que es similar para el lector, así que tal vez use esta en lugar de la más clara cuando el tiempo de ejecución es importante. Usé la versión estricta para esto.