¿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?

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 .

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.

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 #.