haskell - traduccion - Monad en términos no de programación

monads scala (10)

¿Hay algún concepto / cosa fuera de la programación (fuera de toda programación, no solo FP) de la que se podría decir que actúa o se parece a una mónada de una manera significativa?

Sí, de hecho lo hay. Las mónadas están relacionadas directamente con la "posibilidad" en la lógica modal por una extensión del isomorfismo de Curry-Howard. (Ver: Una reconstrucción crítica de lógica modal ) .

Esta es una relación bastante fuerte, y para mí los conceptos relacionados con la posibilidad en el lado lógico son más intuitivos que los relacionados con las mónadas de la teoría de categorías. La mejor manera que he encontrado para explicar las mónadas a mis alumnos se basa en esta relación, pero sin mostrar explícitamente el isomorfismo.

La idea básica es que, sin mónadas, todas las expresiones existen en el mismo mundo, y todos los cálculos se realizan en ese mundo. Pero con las mónadas puede haber muchos mundos y el cálculo se mueve entre ellos. (por ejemplo, cada mundo podría especificar el valor actual de algún estado mutable)

En esta vista, una mónada p significa "en un mundo posible accesible desde el mundo actual".

En particular, si t es un tipo, entonces:

x :: t significa que algo de tipo t está directamente disponible en el mundo actual
y :: pt significa que algo del tipo t está disponible en un mundo accesible desde el actual

Entonces, el return nos permite usar el mundo actual como accesible.

return :: t -> pt

Y >>= nos permite hacer uso de algo en un mundo alcanzable y luego alcanzar mundos adicionales de ese mundo.

(>>=) :: pt -> (t -> ps) -> ps

Entonces >>= puede usarse para construir un camino a un mundo alcanzable desde caminos más pequeños a través de otros mundos.

Con los mundos como estados, esto es bastante fácil de explicar. Para algo así como una mónada IO, también es bastante fácil: un mundo se especifica por todas las interacciones que un programa ha tenido con el mundo exterior.

Para la no terminación son suficientes dos mundos: el ordinario y el infinito en el futuro. (Aplicar >> = con el segundo mundo está permitido, pero es poco probable que observes lo que sucede en ese mundo). Para una mónada de continuación, el mundo sigue siendo el mismo cuando las continuaciones se usan normalmente, y hay mundos adicionales para cuando no son (por ejemplo, para callcc).

Posible duplicado:
¿Qué es una mónada?

¿Cómo describirías una mónada en términos que no sean de programación? ¿Hay algún concepto / cosa fuera de la programación (fuera de toda programación, no solo FP) de la que se podría decir que actúa o se parece a una mónada de una manera significativa?

Aquí está mi puñalada actual:

Las mónadas son brigadas de cubos :

Cada operación es una persona haciendo cola; es decir, hay una secuencia inequívoca en la que tienen lugar las operaciones.
Cada persona toma un cubo como entrada, saca cosas de él y pone cosas nuevas en el cubo. El cubo, a su vez, se pasa a la siguiente persona en la brigada (a través de la operación bind, o >>= ,).
La operación de return es simplemente la operación de poner cosas en el cubo.
En el caso de operaciones de secuencia ( >> ), el contenido del cubo se descarga antes de pasarlo a la siguiente persona. A la siguiente persona no le importa lo que haya en el cubo, solo está esperando recibirla.
En el caso de las mónadas en () , se está transfiriendo un ticket dentro del contenedor. Se llama "la Unidad", y es solo una hoja de papel en blanco.
En el caso de las mónadas IO, cada persona dice algo en voz alta que es totalmente profunda o completamente estúpida, pero solo pueden hablar cuando sostienen el cubo.

Espero que esto ayude. :-)

Editar: Agradezco su apoyo, pero, por desgracia, la maldición Tutorial Mónada ha atacado de nuevo. Lo que he descrito es simplemente la aplicación de funciones con contenedores, ¡no con mónadas! Pero no soy nihilista. ¡Creo que la maldición de Monad Tutorial se puede romper! Así que aquí hay algo más, um, una imagen complicada que creo que lo describe un poco mejor. Tú decides si vale la pena llevarlo a tus amigos.

Las mónadas son una brigada de cubos con gerentes de proyecto . Los gerentes de proyecto respaldan a todos menos al primer miembro de la brigada. Los miembros de la brigada de baldes están sentados en banquetas y tienen cubos delante de ellos.

La primera persona recibe algunas cosas, hace algo con eso y lo pone en un cubo. Esa persona luego se da el paso, no a la siguiente persona en la brigada, ¡eso sería demasiado fácil! :-) - pero al gerente de proyecto detrás de esa persona.

El administrador del proyecto (su nombre es bind , o >>= ) toma el cubo y decide qué hacer con él. Ella puede decidir sacar las cosas de la primera persona del cubo y simplemente dárselas a la persona que tiene delante sin más preámbulos (esa es la mónada IO). Ella puede elegir arrojar el cubo y terminar la brigada (eso es un fail ). Puede decidir pasar por alto a la persona que tiene delante y pasar el cubo al siguiente gerente de la brigada sin más preámbulos (eso es lo que sucede con Nothing en la mónada Maybe ). ¡Incluso puede decidir sacar las cosas de la cubeta y entregárselas a la persona que tiene delante una pieza a la vez! (Esa es la mónada de la Lista.) En el caso de la secuencia ( >> ), simplemente toca el hombro de la persona que tiene delante, en lugar de darles cualquier cosa.

Cuando la siguiente persona hace un cubo de cosas, la persona se lo entrega al siguiente gerente de proyecto. El próximo gerente de proyecto se da cuenta de nuevo qué hacer con el cubo que le ha dado, y le pasa las cosas en el cubo a su persona. Al final, el cubo se pasa de nuevo a la cadena de administradores de proyecto, que opcionalmente puede hacer cosas con el cubo (como la mónada List ensamblar todos los resultados). El primer gerente de proyecto produce un cubo de cosas como resultado.

En el caso de la sintaxis do , cada persona es en realidad una operación que se define in situ en el contexto de todo lo que pasó antes, como si el administrador del proyecto transfiriera no solo lo que está en el cubo, sino también los valores (er, cosas ) que han sido generados por los miembros anteriores de la brigada. La construcción de contexto en este caso es mucho más fácil de ver si se escribe el cálculo usando bind y sequence en lugar de usar la sintaxis do : note que cada "declaración" sucesiva es una función anónima construida dentro de la operación que está precedida por ese punto.

() los valores, las mónadas IO y la operación de return permanecen descritas como arriba.

"¡Pero esto es demasiado complicado! ¿Por qué la gente no puede simplemente descargar los cubos?" Te escucho preguntar Bueno, el gerente de proyecto puede hacer un montón de trabajo detrás de escena que de otra manera complicaría el trabajo de la persona. Estamos tratando de facilitar las cosas a estos miembros de la brigada, para que no tengan que hacer demasiado. En el caso de la Mónada Maybe, por ejemplo, cada persona no tiene que verificar el valor de lo que se le da para ver si recibió Nada, el gerente del proyecto se encarga de eso.

"Bueno, entonces, si realmente estás tratando de facilitar el trabajo de cada persona, ¿por qué no hacerlo todo el tiempo? ¿Una persona simplemente toma cosas y entrega cosas, y deja que el gerente del proyecto se preocupe por el cubo?" Eso a menudo se hace, y tiene un nombre especial llamado levantar a la persona (er, operación) en la mónada . A veces, sin embargo, quieres a una persona que tiene algo un poco más complicado que hacer, donde quiere tener cierto control sobre el cubo que se produce (por ejemplo, si necesitan devolver Nothing en el caso de la mónada Quiz), y eso es lo que la mónada en generalidad general proporciona.

Los puntos son:

Las operaciones están secuenciadas.
Cada persona sabe cómo hacer cubos, pero no cómo sacar cosas de los cubos.
Cada gerente de proyecto sabe cómo lidiar con los cubos, y cómo obtener cosas de ellos, pero no le importa lo que hay en ellos.

Así termina mi tutorial a la hora de dormir. :-PAG

Bueno, aquí hay una descripción muy detallada de mónadas que definitivamente está fuera de toda programación. Sé que está fuera de la programación porque soy programador y no entiendo ni la mitad de lo que dice.

También hay una serie de videos en YouTube que explica las mónadas de esa variedad: esta es la primera de la secuencia .

Supongo que eso no es realmente lo que estabas buscando, aunque ...

De esta excelente publicación de Mike Vanier,

Uno de los conceptos clave en Haskell que lo diferencia de otros lenguajes de programación es el concepto de una "mónada". Las personas parecen encontrar esto difícil de aprender (lo hice también), y como resultado hay montones de tutoriales de mónada en la web, algunos de los cuales son muy buenos (particularmente me gusta All About Monads por Jeff Newbern). Incluso se ha dicho que escribir un tutorial de mónada es un rito de iniciación para los nuevos programadores de Haskell. Sin embargo, un gran problema con muchos tutoriales de mónada es que intentan explicar qué mónadas son en referencia a conceptos existentes que el lector ya entiende (incluso he visto esto en presentaciones de Simon Peyton-Jones, el autor principal del compilador de GHC). y el general Haskell grand poobah). Esto es un error, y voy a decirte por qué.
Al tratar de explicar qué es algo, es natural explicarlo haciendo referencia a cosas que la otra persona ya conoce. Esto funciona bien cuando lo nuevo es similar en algunos aspectos a cosas con las que la otra persona está familiarizada. Se descompone por completo cuando lo nuevo está completamente fuera de la experiencia de la persona que lo está aprendiendo. Por ejemplo, si estuvieras tratando de explicar qué es el fuego para un hombre de las cavernas que nunca había visto un incendio, ¿qué dirías? "Es como un cruce entre aire y agua, pero caliente ..." No muy efectivo. Del mismo modo, explicar qué es un átomo en términos de mecánica cuántica es problemático, porque sabemos que el electrón realmente no orbita alrededor del núcleo como un planeta alrededor de una estrella, y la noción de una "nube de electrones deslocalizada" realmente no significa mucho. Feynman dijo una vez que nadie realmente entendía la mecánica cuántica, y en un nivel intuitivo eso es verdad. Pero a nivel matemático, la mecánica cuántica es bien conocida; simplemente no tenemos una buena intuición para lo que realmente significan las matemáticas.
¿Cómo se relaciona esto con las mónadas? Una y otra vez, en tutoriales, publicaciones de blog y en las listas de correo de Haskell, he visto las mónadas explicadas de una de las dos formas supuestamente intuitivas: una mónada es "algo así como una acción" o "algo así como un contenedor". ¿Cómo puede algo ser tanto una acción como un contenedor? ¿No son estos conceptos separados? ¿Es una mónada una especie de "contenedor activo" raro? No, pero el punto es que afirmar que una mónada es un tipo de acción o un tipo de contenedor es incorrecto. Entonces, ¿qué es una mónada, de todos modos?
Aquí está la respuesta: una mónada es un concepto puramente abstracto, sin relación fundamental con nada de lo que hayas oído hablar antes. La noción de una mónada proviene de la teoría de categorías, que es la rama más abstracta de las matemáticas que conozco. De hecho, el objetivo de la teoría de categorías es abstraer toda la estructura de las matemáticas para exponer las similitudes y analogías entre áreas aparentemente dispares (por ejemplo, entre álgebra y topología), a fin de condensar las matemáticas en sus conceptos fundamentales, y por lo tanto, reducir la redundancia. (Podría continuar sobre esto durante bastante tiempo, pero prefiero volver al punto que estoy tratando de plantear). Como supongo que la mayoría de los programadores que están aprendiendo sobre Haskell no saben mucho sobre la teoría de categorías, las mónadas no van a significar nada para ellos. Eso no significa que necesiten aprender todo sobre la teoría de categorías para usar mónadas en Haskell (afortunadamente), pero sí significa que necesitan sentirse cómodos pensando en las cosas de una manera más abstracta de lo que probablemente estén acostumbrados.

Por favor diríjase al enlace en la parte superior de la publicación para leer el artículo completo.

Depende de con quién estés hablando. Cualquier explicación tiene que ser lanzada en el nivel correcto. Mi explicación para un ingeniero químico sería diferente a mi explicación para un matemático o un gerente de finanzas.

El mejor enfoque es relacionarlo con algo en la experiencia de la persona con la que está hablando. Como regla general, la secuenciación es un problema bastante universal, así que trate de encontrar algo que la persona sepa acerca de dónde dice "primero haz X, luego haz Y". Luego explica cómo los lenguajes de programación comunes tienen un problema con eso; si dices "haz X, haz Y" a una computadora, hace X e Y inmediatamente sin esperar a que ingrese más información, pero no puede hacer Z mientras tanto para otra persona; la idea de la computadora de "y luego hacer" es diferente a la tuya. Por lo tanto, los programadores tienen que escribir sus programas de forma diferente a como lo explicaría usted (el experto). Esto crea una brecha entre lo que dices y lo que dice el programa. Cuesta tiempo y dinero cruzar esa brecha.

Las mónadas le permiten poner su versión de "y luego hacer" en la computadora, por lo que puede decir "hacer X y luego hacer Y", y el programador puede escribir "do {x; y}", y significa lo que quiere decir.

En la práctica, la mayoría de las mónadas con las que he trabajado se comportan como un tipo de contexto implícito.

Es como cuando tú y un amigo están tratando de tener una conversación sobre un amigo en común. Cada vez que dices "Bob", los dos se refieren al mismo Bob, y ese hecho se enhebra implícitamente a través de su conversación debido al contexto en el que Bob es su amigo en común.

Por supuesto, puede conversar con su jefe (no con su amigo) sobre su gerente de nivel de omisión (no su amigo) que se llama Bob. Aquí puede tener otra conversación, nuevamente con alguna connotación implícita que solo tiene sentido dentro del contexto de la conversación. Incluso puede pronunciar exactamente las mismas palabras que hizo con su amigo, pero tendrán un significado diferente debido a los diferentes contextos.

En la programación, es lo mismo. La forma en que se comporta tell depende de la mónada en la que se encuentre; la forma en que se ensambla la información ( >>= ) depende de la mónada en la que se encuentre. La misma idea, el modo de conversación diferente.

Diablos, incluso las reglas de la conversación pueden ser monádicas. "No le digas a nadie lo que te dije" oculta la información de la misma manera que runST evita que las referencias escapen de la mónada ST . Obviamente, las conversaciones pueden tener capas y capas de contexto, al igual que tenemos montones de transformadores de mónada.

Espero que ayude.

En términos que no sean de programación:

Si F y G son un par de funtores adjuntos, con F anexa a G , entonces la composición GF es una mónada.

Me gusta pensar en ellos como abstracciones de cálculos que pueden ser "atados". O, burritos!

Sí, Monads proviene de un concepto fuera de haskell. Haskell tiene muchos términos e ideas que han sido tomados de la teoría de categorías. Este es uno de ellos. Entonces, si esta persona que no es programadora resulta ser un matemático que ha estudiado la teoría de categorías, simplemente diga: "una mónada es un monoide en la categoría de endofunctors".

Sí, hay muchas cosas fuera de la programación que pueden decirse que son como mónadas. No, ninguno de ellos te ayudará a entender las mónadas. Por favor, lea Abstracción, intuición y la "falacia del tutorial de mónadas" :

Joe Haskeller está tratando de aprender sobre las mónadas. Después de luchar por entenderlos durante una semana, mirar ejemplos, escribir códigos, leer cosas que otras personas escribieron, finalmente tuvo un momento de "¡Ajá!": ¡Todo está claro de repente, y Joe entiende las Mónadas! Lo que realmente sucedió, por supuesto, es que el cerebro de Joe ha encajado todos los detalles en una abstracción de alto nivel, una metáfora que Joe puede usar para obtener una comprensión intuitiva de las mónadas; supongamos que la metáfora de Joe es que las Mónadas son como Burritos. Aquí es donde Joe malinterpreta mal su propio proceso de pensamiento: "¡Por supuesto!", Piensa Joe. "Todo es muy simple ahora. La clave para entender las mónadas es que son como Burritos. ¡Si hubiera pensado en esto antes! "El problema, por supuesto, es que si Joe hubiera pensado en esto antes, no hubiera ayudado: la semana de luchar por los detalles fue una parte necesaria e integral de la formación de la intuición de Joe''s Burrito , no es una triste consecuencia de su fracaso para alcanzar la idea antes.
Pero ahora Joe va y escribe un tutorial de mónada llamado "Las mónadas son burritos", bajo la suposición bien intencionada pero errónea de que si otras personas leen su visión mágica, aprender sobre las mónadas será muy fácil para ellas. "Las mónadas son fáciles", escribe Joe. "Piense en ellos como burritos". Joe esconde todos los detalles reales sobre los tipos y cosas así porque son aterradores, y las personas aprenderán mejor si pueden evitar todas esas cosas difíciles y confusas. Por supuesto, exactamente lo contrario es cierto, y lo único que Joe ha hecho es dificultar que la gente aprenda sobre las mónadas, porque ahora tienen que pasar una semana pensando que las mónadas son burritos y se confunden por completo, y luego una semana tratando de olvidar sobre la analogía del burrito, antes de que realmente puedan dedicarse al negocio de aprender acerca de las mónadas.

Como dije en otra respuesta hace mucho tiempo, ¡el artículo de sigfpe Podrías haber inventado mónadas! (Y quizás ya lo haya hecho) , así como el documento original de Philip Wadler, Mónadas para programación funcional , son presentaciones excelentes (que no dan analogías, sino muchos ejemplos), pero más allá de eso, simplemente siguen codificando, y finalmente todo parecerá trivial.

[No es una respuesta real: un lugar donde existen mónadas fuera de toda programación, por supuesto, está en matemáticas. Como este hilarante post señala, "una mónada es un monoide en la categoría de endofunctors, ¿cuál es el problema?" :-)]

Editar : El interlocutor parece haber interpretado esta respuesta como condescendiente, diciendo algo así como "Las mónadas son tan complicadas que están más allá de la analogía". De hecho, no se pretendía nada por el estilo, y son mónadas-analogías que a menudo parecen condescendientes . Tal vez debería replantear mi punto como " No tienes que entender las mónadas ". Usas mónadas particulares porque son útiles: utilizas la mónada Maybe cuando necesitas los tipos Maybe, usas la mónada IO cuando necesitas hacer IO, de manera similar otros ejemplos , y aparentemente en C # , usas el patrón Nullable <>, LINQ y comprensión de consultas, etc. Ahora, la idea de que existe una única abstracción general subyacente a todas estas estructuras, que llamamos una mónada, no es necesaria para comprender o usar las mónadas específicas. Es algo que puede venir como una ocurrencia tardía, después de haber visto más de un ejemplo y reconocer un patrón: el aprendizaje procede de lo concreto a lo abstracto. Explicar directamente la abstracción, apelando a las analogías de la abstracción en sí misma, no suele ayudar al alumno a captar de qué se trata.