c# - ¿Tiene sentido la E/S iterativa en lenguajes no funcionales?
haskell iteration (2)
En Haskell, la E / S basada en Iteratee parece muy atractiva. Los iterados son una forma compacta, segura y rápida de hacer I / O inspirada por la función ''fold'', también llamada ''reducir'', en lenguajes funcionales. Básicamente, si tiene un recorrido general, la idea es encapsular el estado transversal en un llamado "enumerador" que llama al "iterador", que a su vez es una función que devuelve un valor o una solicitud de más datos junto con una continuación para El enumerador para llamar. Por lo tanto, solo el enumerador conoce el estado del recorrido, mientras que el iterador sabe qué hacer con los datos y construye valores a partir de ellos. Lo bueno de esto es que las iteraciones se pueden componer automáticamente, donde la salida de una iteración se alimenta a otra para hacer una más grande.
Entonces, dos preguntas:
- ¿El concepto tiene sentido en otros lenguajes, como los lenguajes orientados a objetos simples o es solo útil para superar las deficiencias de la perezosa I / O de Haskell?
- ¿Hay implementaciones reales para otros idiomas, especialmente C # (ya que eso es lo que usa mi empresa)? (Una búsqueda en Google muestra una mención de iteraciones en Scala; bueno, en este momento no estoy interesado en Scala).
Si entiendo lo que estás describiendo, se parece mucho a las Extensiones reactivas :
http://channel9.msdn.com/Tags/reactive+extensions
Erik Meijer explica cómo IObservable es el doble matemático de IEnumerable aquí:
En primer lugar, tenga en cuenta que el "Lazy IO" de Haskell es un tipo de piratería que rompe la pureza de una manera limitada para permitir que se produzca la E / S bajo demanda, ya que los datos se consumen perezosamente. Esto es normal en un lenguaje impuro, y las secuencias perezosas pueden crear el mismo problema en cualquier lugar. Entonces, si está haciendo algo como, por ejemplo, exponer una interfaz IEnumerable a un archivo y leerla de manera incremental a medida que se enumera la secuencia, esto no es realmente diferente.
En segundo lugar, las iteraciones y los enumeradores también se pueden componer en lo que se denominan enumerados (de manera algo torpe). En este punto, se está alimentando algo de datos secuenciales, produciendo resultados incrementales a medida que están listos, y alimentando esos resultados a otra cosa. Básicamente, se trata de una variedad de procesadores de flujo, un concepto que probablemente precede tanto a Haskell como a C # por un margen considerable.
En tercer lugar, las iteraciones son una encapsulación de comportamiento abstraído, con su funcionamiento interno oculto. Podría decirse que esto es más acorde con los principios de OO que con la programación funcional de estilo ML, al menos en el sentido de los "principios de OO" que defienden las personas que le gritan por usar captadores y definidores y piensan que el flujo de control debe implementarse a través de polimorfismo.
Teniendo en cuenta lo anterior, diría que el concepto de iterado se ajustaría perfectamente a C #, y se implementaría de forma más natural como una especie de equivalente invertido de IEnumerable , con objetos de flujo de datos de composición y una interfaz "push" en lugar de la estándar Estilo "pull" de LINQ.