![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
sab123С подачи http://ivan-gandhi.livejournal.com/2800521.html?thread=41990281#t41990281 поковырял я хаскельные монады поглубже.
Как оказалось, википедия традиционно соврала (ну, не совсем, но наполовину). Пример в подаче тоже хитрый и при первом взгляде выглядит не тем, чем является на самом деле (и этим способствовал пониманию). По первому пункту, про конвейер, я оказался совершенно прав. А второй пункт оказался всего лишь частным случаем, который в вике заявлен универсальным.
Теперь в деталях про конвейер. Конвейер совершенно прямой и фиксированный.
Никаких разветвлений, все в одну линию. То, что на первый взгляд может показаться разветвлениями (вложенные do) - никакие не разветвления, а просто маленькие конвейеры, вложенные в одну ступень родительского конвейера. Никакие if/else применяться для разветвления тоже не могут - они всего лишь ветвления логики внутри одной ступени, а результат из ступени должен всегда выйти однотипный и в одном направлении.
Количество ступеней в конвейере фиксировано. Вот сколько под-элементов написано в do - столько и будет ступеней. Не все данные могут доехать до последней ступени, но сами ступени от этого никуда не деваются. Вероятно, конвейеры можно строить динамически, но когда они построены и конвейер запущен, то уже ничего никуда менять нельзя.
Каждая ступень конвейера видит состояние, объемлющее конвейер, плюс каждая передаваемая запись несет в себе соостояние всех предыдущих ступеней конвейера. Все это состояние доступно только для чтения. Состояние, добавляемое каждой ступенью, можно рассматривать как фрейм scope. (Замыканием оно не является, поскольку не является функцией). В виде реакции на одну полученную запись, ступень может выдать некое количество (возможно ноль) записей на выход, добавив в каждую из этих записей свое состояние (меняющееся для каждой записи).
Функтор - это правила, определяющие:
1) правила построения состояния каждой ступени исходя из видимого этой ступенью внешнего состояния, и как следствие - формат фрейма в записях, посылаемых этой ступенью, и ограничения на количество этих записей
3) правила сбора результатов из последней ступени для возврата владельцу конвейера
Владелец конвейера может получить результаты из конвейера только после того, как закончит посылать туда данные.
Кстати, это хозяйство интересно накладывается на поточную обработку в CEP, и является сильно упрощенным ее вариантом. Упрощение приводит с одной стороны к легкости параллелизации, с другой стороны - к сильно уменьшенной функциональности и тому, что конвейеры будут короткими и их придется постоянно запускать и останавливать, чтобы извлечь результаты, так что вся теоретическая легкость параллелизации потеряется.
Как оказалось, википедия традиционно соврала (ну, не совсем, но наполовину). Пример в подаче тоже хитрый и при первом взгляде выглядит не тем, чем является на самом деле (и этим способствовал пониманию). По первому пункту, про конвейер, я оказался совершенно прав. А второй пункт оказался всего лишь частным случаем, который в вике заявлен универсальным.
Теперь в деталях про конвейер. Конвейер совершенно прямой и фиксированный.
Никаких разветвлений, все в одну линию. То, что на первый взгляд может показаться разветвлениями (вложенные do) - никакие не разветвления, а просто маленькие конвейеры, вложенные в одну ступень родительского конвейера. Никакие if/else применяться для разветвления тоже не могут - они всего лишь ветвления логики внутри одной ступени, а результат из ступени должен всегда выйти однотипный и в одном направлении.
Количество ступеней в конвейере фиксировано. Вот сколько под-элементов написано в do - столько и будет ступеней. Не все данные могут доехать до последней ступени, но сами ступени от этого никуда не деваются. Вероятно, конвейеры можно строить динамически, но когда они построены и конвейер запущен, то уже ничего никуда менять нельзя.
Каждая ступень конвейера видит состояние, объемлющее конвейер, плюс каждая передаваемая запись несет в себе соостояние всех предыдущих ступеней конвейера. Все это состояние доступно только для чтения. Состояние, добавляемое каждой ступенью, можно рассматривать как фрейм scope. (Замыканием оно не является, поскольку не является функцией). В виде реакции на одну полученную запись, ступень может выдать некое количество (возможно ноль) записей на выход, добавив в каждую из этих записей свое состояние (меняющееся для каждой записи).
Функтор - это правила, определяющие:
1) правила построения состояния каждой ступени исходя из видимого этой ступенью внешнего состояния, и как следствие - формат фрейма в записях, посылаемых этой ступенью, и ограничения на количество этих записей
3) правила сбора результатов из последней ступени для возврата владельцу конвейера
Владелец конвейера может получить результаты из конвейера только после того, как закончит посылать туда данные.
Кстати, это хозяйство интересно накладывается на поточную обработку в CEP, и является сильно упрощенным ее вариантом. Упрощение приводит с одной стороны к легкости параллелизации, с другой стороны - к сильно уменьшенной функциональности и тому, что конвейеры будут короткими и их придется постоянно запускать и останавливать, чтобы извлечь результаты, так что вся теоретическая легкость параллелизации потеряется.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2014-07-11 05:20 pm (UTC)no subject
Date: 2014-07-11 05:51 pm (UTC)