Czy iteratee I/O ma sens w niefunkcjonalnych językach?

Question

W Haskell, Iteratee based I/O wydaje się bardzo atrakcyjny. Iteratees to składane, bezpieczne i szybkie sposoby na wykonywanie operacji wejścia/wyjścia inspirowane funkcją "fold" a.k.a. "reduce" w językach funkcjonalnych. Zasadniczo, jeśli masz ruch, chodzi o enkapsulację stanu przejścia do tak zwanego "modułu wyliczającego", który wywołuje "iteratee", który z kolei jest funkcją zwracającą wartość lub żądanie więcej danych wraz z kontynuacją aby moduł wyszukujący mógł zadzwonić. Tak więc tylko moduł wyliczający zna stan przejścia, a iteratee wie, co zrobić z danymi i buduje z nich wartości. Zaletą jest to, że iteraty są automatycznie kompozycyjne, gdzie wyjście jednego iteratee jest przekazywane do drugiego, aby zrobić większy.

Więc dwa pytania:

• Czy pojęcie nawet zrobić sence w innych językach, jak zwykły językach obiektowych czy jest to przydatne tylko dla przezwyciężenia braków Haskell za leniwa I/O?
• Czy są jakieś rzeczywiste implementacje dla innych języków, szczególnie C# (jak to jest to, czego używa moja firma)? (W wyszukiwarce Google pojawia się jedna wzmianka o iteratach w Scali, cóż, nie jestem teraz zainteresowany Scalą).

Answer 1

Jeśli dobrze rozumiem to, co opisujesz, to brzmi strasznie dużo jakby Reactive Extensions:

http://channel9.msdn.com/Tags/reactive+extensions

Erik Meijer wyjaśnia jak IObservable jest matematyczny podwójny z IEnumerable tutaj:

http://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-Brian-Beckman-and-Erik-Meijer-Inside-the-NET-Reactive-Framework-Rx

Answer 2

Przede wszystkim uświadomić sobie, że Haskell w „Lazy IO” to rodzaj hack, który rozkłada czystość w ograniczony sposób, aby umożliwić I/O, aby pojawić się na żądanie, jak dane są spożywane leniwie. Jest to normalne działanie w nieczystym języku, a leniwy ciąg może stworzyć ten sam problem w dowolnym miejscu. Więc jeśli robisz coś takiego, powiedzmy, pokazując interfejs IEnumerable do pliku i czytając go przyrostowo w miarę wyliczania sekwencji, to tak naprawdę nie jest inaczej.

Po drugie, iteraty i enumeratory mogą być również składane w tak zwane (w nieco niezdarnym stylu) enumeratees. W tym momencie masz coś, co jest zasilane danymi sekwencyjnymi, tworząc przyrostowe wyniki, gdy są gotowe, i dostarczając te wyniki do czegoś innego. Jest to w zasadzie wiele procesorów strumieniowych, których koncepcja prawdopodobnie znacznie wyprzedza zarówno Haskella, jak i C#.

Po trzecie, iteraty są enkapsulacją abstrakcyjnych zachowań, z ich wewnętrznymi działaniami ukrytymi. Jest to prawdopodobnie bardziej zgodne z zasadami OO niż z programowaniem funkcjonalnym w stylu ML, przynajmniej w sensie "zasad OO", które są popierane przez ludzi, którzy krzyczą na ciebie za używanie modułów pobierających i ustawiających i myślę, że przepływ kontroli powinien być realizowany za pośrednictwem wielopostaciowość.

Biorąc pod uwagę powyższe, powiedziałbym, że koncepcja iteratee pasowałaby dobrze w języku C# i byłaby najbardziej naturalnie zaimplementowana jako odwrócony odpowiednik IEnumerable, z obiektami przepływu danych kompozycyjnych i interfejsem "push" zamiast standardowego stylu "pull" LINQ.