¿Cómo se relaciona la mónada tal vez con el tipo de opción?

Estaba haciendo una presentación sobre F # y estaba discutiendo el tipo de Opción cuando alguien en la audiencia me preguntó si el tipo de Opción es la implementación de F # de la mónada quizás. Sé que ese no es el caso, pero quería preguntar cómo se relacionan los dos conceptos. Quiero decir que me parece que un tipo de opción podría ser el resultado de la operación de una mónada, pero ni siquiera estoy seguro de eso.

¿Alguien aclararía la relación entre tal vez la mónada y el tipo de opción en esos lenguajes funcionales que lo admiten?

functional-programming monad

— Onorio Catenacci
fuente

Solo curiosidad, pero ¿cómo lo sabes that's not the case? Se parecen mucho a mí.

Por eso estoy preguntando.

— Onorio Catenacci

Respuestas:

Al leer la documentación sobre el tipo de F # Option, parece que se comporta casi exactamente como el Maybetipo en Haskell, en el sentido de que puede modelar 'nada' ( Noneen F #, Nothingen Haskell) o un valor de su tipo de argumento ( Someen F #, Justen Haskell)

En Haskell, sin embargo, Maybetambién es una mónada, y la plomería es tal que permite el cálculo de los Maybevalores, lo que devuelve anticipadamente Nothingsi alguna de las variables en el cálculo lo es Nothing. Utilizado de esta manera, Maybees un simple controlador de errores (o más bien, un dispositivo que ignora los errores), y el hecho de que sea una mónada permite mover la caldera fuera del camino. Mira este artículo de Wikipedia para un buen ejemplo conciso. No creo que sea Optioncompatible con este tipo de uso monádico (de hecho, me pregunto si hay algún concepto explícito de una mónada en F #). Si desea este comportamiento en .NET, supongo que lo usaría Option.Valuepara todos sus argumentos y envolvería todo el cálculo en un intento / captura NullReferenceException.

Entonces, si bien Optiones similar al Maybe tipo , no es equivalente a la Maybe mónada .

— tdammers
fuente

Gracias por la lúcida explicación. Francamente, siempre consideré que no eran lo mismo (uno es un tipo, el otro es una mónada), pero no estaba del todo claro sobre cómo uno se relacionaba con el otro.

— Onorio Catenacci

Por cierto, hay un tipo de concepto de mónada en F #; Se llama una expresión de cálculo.

— Onorio Catenacci

@OnorioCatenacci: Ah, está bien. No he tenido mucha exposición a F #, así que discúlpeme. De todos modos, en Haskell, las mónadas son tipos, más específicamente, tipos de la clase de tipos Monad. Maybees un tipo de datos antiguo, pero también se implementa Monadpara proporcionar este comportamiento 'especial'.

— tdammers

en resumen: no estoy de acuerdo con que no sean equivalentes. construcciones de lenguaje como clases de tipos o polimorfismo no cambian las propiedades y la estructura matemática fundamental de un tipo

— sara

Las opciones mapy bindfunciones de F # se comportan de manera idéntica a las funciones fmapy bindfunciones de Quizás de Haskell . Ambos son mónadas y tienen un comportamiento monádico equivalente. Haskell solo tiene una Monadclase de tipos que le permite manipular mónadas, mientras que en F # son más como un "patrón de diseño" abstracto.

— Jack

Sí, son equivalentes en el sentido de que el Optiontipo junto con el Option.bindconstructor de tipos Someconstituyen una mónada.

Si bien las mónadas (como en la Monadclase de tipos) son una parte central de la identidad de Haskells, desde un punto de vista conceptual son una construcción independiente del lenguaje. Un patrón de diseño si quieres. Si tiene un tipo, y tiene un enlace y una función de retorno con firmas específicas que obedecen a un conjunto particular de leyes, tiene una mónada, independientemente del idioma que use.

Las expresiones de cálculo F # solo proporcionan un azúcar de sintaxis programable para mónadas, similar a la notación do en Haskell. Si bien no hay un Optiongenerador de expresiones de cálculo provisto de fábrica, puede definir fácilmente uno básico como este:

type OptionBuilder () = 
    member this.Bind(m, f) = Option.bind f m
    member this.Return(a) = Some a 

let option = OptionBuilder ()

Y úsalo así:

let c = 
    option {
        let! a = Some 4
        let! b = None
        return a + b
    }

que es un equivalente azucarado de algo como esto:

let c =
    (Some 4) 
    |> Option.bind (fun a ->
        None 
        |> Option.bind (fun b ->
             Some (a + b)))

Observe cómo los miembros del constructor reflejan la Monadclase de tipo y cómo puede escribir código monádico, incluso si es complicado, sin un generador.

— scrwtp
fuente

Son equivalentes, y ambas son mónadas. La diferencia es que ser una mónada significa algo en Haskell: hay una Monadclase de tipo explícita y se puede usar "hacer notación" para eliminar muchas repeticiones al escribir código monádico. En F #, notación constructor y let!y do!se puede utilizar para deshacerse de texto modelo similar, pero hay no una noción explícita de un tipo de "ser una mónada". El sistema de tipos de Haskell incluye clases de tipos (de las cuales es la Monadclase general ) y tipos de tipo superior (de los cuales es un individuo Monad), que permiten escribir código que funciona para todas las mónadas. El sistema de tipos de F # no tiene ninguna de estas características.

Entonces sí, F # 's Optiony Haskell's Maybeson idénticos y ambas mónadas. Es solo que Haskell te da mucha más maquinaria para trabajar con mónadas que F #.

— Jack
fuente