19 votos

¿Cómo llaman a los datos ajusta dentro de una mónada?

En el habla y la escritura, sigo queriendo referirse a los datos dentro de una mónada, pero no sé cómo llamarlo.

Por ejemplo, en la Scala, el argumento de la función se pasa a flatMap obtiene une...er...que cosa dentro de la mónada. En:

List(1, 2, 3).flatMap(x => List(x, x))

x obtiene enlazado a esa cosa que no tiene una palabra para.

Complicando un poco las cosas, el argumento pasado a la Kleisli flecha no necesariamente te obligado a todos los datos dentro de la mónada. Con List, Set, Stream, y un montón de otras mónadas, flatMap llama a la Kleisli flecha muchas veces, la unión x a una pieza diferente de los datos dentro de la mónada cada momento. O tal vez ni siquiera a los "datos", tan largo como la mónada de las leyes se cumplan. Sea lo que sea, se envuelve en el interior de la mónada, y flatMap pasa a usted, sin el contenedor, tal vez una pieza a la vez. Sólo quiero saber qué llamar a la relevante dentro de la mónada cosas que x se refiere a que, al menos en parte, para que yo pueda dejar de mit todo esto fumbly idioma.

Hay un estándar o convencional plazo para esta cosa/datos/valor/cosas/lo-que-es?

Si no, ¿qué hay de "los dulces"?

17voto

Dan Burton Puntos 26639

Tratando de decir "x obtiene obligado a" es el valor que para el fracaso. Me explico, y la guía hacia una mejor forma de expresarse cuando se habla de este tipo de cosas.

Supongamos que tenemos:

someList.flatMap(x => some_expression)

Si sabemos que algunalista ha escriba List[Int], entonces podemos decir con seguridad que en el interior de some_expression, x está vinculado a un valor de tipo Int. Observe la advertencia de que, "dentro de some_expression". Esto es debido a que, dado someList = List(1,2,3), x tomará los valores de cada uno de ellos: 1, 2y 3, en turno.

Considere la posibilidad de una más generalizada ejemplo:

someMonadicValue.flatMap(x => some_expression)

Si no sabemos nada acerca de la someMonadicValue, entonces no sabemos mucho acerca de cómo some_expression va a ser invocado. Se puede ejecutar una vez o tres veces (como en el ejemplo de arriba), o por pereza, o de forma asíncrona, o puede ser programado para una vez someMonadicValue está terminado (por ejemplo, futuros), o que nunca podrán ser utilizados (por ejemplo, lista vacía, Ninguno). La Mónada de la interfaz de no incluir el razonamiento acerca de cuándo o cómo someExpression será utilizado. Así que todo lo que puede decir acerca de lo x va a ser confinado en el contexto de la some_expression, siempre y sin embargo some_expression pasa a ser evaluados.

Así que volvemos al ejemplo.

someMonadicValue.flatMap(x => some_expression)

Está tratando de decir "x es el ??? de someMonadicValue." Y usted está buscando la palabra que precisa reemplaza ???. Bueno, yo estoy aquí para decirte que estás haciendo mal. Si usted quiere hablar acerca de x, luego de hacerlo

  1. En el contexto de la some_expression. En este caso, el uso de la frase en negrita que te di anteriormente: "en el interior de some_expression, x está vinculado a un valor de tipo Foo." O, alternativamente, usted puede hablar acerca de la x...
  2. Con el conocimiento adicional acerca de la mónada que usted está tratando.

En el caso #2, por ejemplo, para someList.flatMap(x => some_expression), usted podría decir que "x es que cada elemento de la someList." Para someFuture.flatMap(x => some_expression), usted podría decir que "x es el éxito para el futuro valor de someFuture, si realmente nunca se completa y se realiza correctamente."

Ves, esa es la belleza de las Mónadas. Que ??? que usted está tratando de describir, es lo que la Mónada de la interfaz de resúmenes de más. Ahora ves por qué es tan difícil dar ??? un nombre? Es porque tiene un nombre diferente y con un significado diferente para cada mónada. Y ese es el punto de tener la Mónada de la abstracción: unificar estos diferentes conceptos bajo la misma interfaz computacional.

1voto

bluenote10 Puntos 1932

Descargo de responsabilidad: definitivamente, no soy un experto en programación funcional terminología y espero que el siguiente no será una respuesta a su pregunta desde su punto de vista. Para mí, el problema más bien es: Si la elección de un término que requiere el conocimiento de los expertos, así lo hace el entendimiento.

La elección de un término adecuado depende en gran medida de:

  • el nivel deseado de corrección lingüística, y
  • su público, y las correspondientes connotaciones de ciertos términos.

Con respecto a la corrección lingüística, la pregunta es si usted correctamente referirse a los valores o los datos que están obligados a x, o si usted puede vivir con una cierta (incorrecto) la abstracción. En términos de la audiencia, me gustaría principalmente diferenciar entre un público con una sólida experiencia en programación funcional y un público que viene de otros paradigmas de programación. En el primer caso, la elección del término probablemente no es totalmente crucial, ya que el concepto en sí es familiar, y muchos términos que llevaría a la derecha de la asociación. La discusión en los comentarios ya contiene algunas sugerencias muy buenas para este caso. Sin embargo, el debate también se muestra que se necesita un cierto fondo en la programación funcional para ver la lógica detrás de algunos términos.

Para un público sin experiencia en programación funcional, prefiero sacrificar corrección lingüística en favor de la comprensión. En tal situación que a menudo sólo se refieren a ella como "tipo subyacente", sólo para evitar cualquier confusión que probablemente voy a crear tratando de referirse a la "cosa(s) en la mónada" a sí mismo. Obviamente, es, literalmente, es incorrecto decir "x está vinculado al tipo subyacente". Sin embargo, es más importante para mí que mi público entiende un concepto que está en todos. Dado que la mayoría de los programadores están familiarizados con los contenedores y sus subyacentes tipos, estoy apuntando para la (errónea) de la asociación "subyacente tipo" => "la cosa(s) que se encuentren en un envase" => "la cosa(s) dentro de una mónada", que a menudo parece que funciona.

TL;DR: siempre Hay un trade-off entre la corrección y la accesibilidad. Y cuando se trata de la programación funcional, a veces es útil para cambiar el sesgo hacia la última.

1voto

Sassa NF Puntos 3181

flatMap no llama a la Kleisli flecha muchas veces. Y "esa cosa" no está "dentro" de la mónada.

flatMap levanta de Kleisli flecha a la mónada. Podría ver esto como la construcción de una flecha M[A] => M[B] entre tipos (A, B) levantó a la mónada (M[A], M[B]), dado un Kleisli flecha A => M[B].

Por lo x en x => f(x) es el valor que se levantó.

1voto

J. Abrahamson Puntos 27606

¿Qué datos?

data Monady a = Monady

Los valores de las mónadas son los valores de las mónadas, sus envuelto tipo puede ser una ficción. Es decir, que hablar de él como si existe puede causar dolor.

Lo que quiero hablar son las continuaciones como Monad m => a -> m b ya que están garantizados para existir. Los chistes se produce en la forma en (>>=) utiliza los continuaciones.

0voto

Thomas W Puntos 7179

'Item' parece bien? 'Parámetro de elemento' si usted necesita para ser más específicos.

El origen de datos puede contener varios elementos, o la operación puede llamar varias veces. Elemento tienden a ser más específicas para el primer caso, el Valor es singular en cuanto a la fuente y no sensible para la lista de usos, pero el Elemento que cubre todos los casos correctamente.

Descargo de responsabilidad: yo sé más sobre comprensible inglés que sobre FP.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X